<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 21, 2017, at 3:43 AM, Axel Rau <<a href="mailto:Axel.Rau@Chaos1.DE" class="">Axel.Rau@Chaos1.DE</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 18.12.2016 um 14:01 schrieb Axel Rau <<a href="mailto:Axel.Rau@chaos1.de" class="">Axel.Rau@chaos1.de</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 18.12.2016 um 00:35 schrieb Andre LaBranche <<a href="mailto:dre@apple.com" class="">dre@apple.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Do you by chance have the default log level set to debug?</span><br style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div>No it is set to ‚warn‘:<div class=""><br class=""></div><div class=""><div class=""> <key>DefaultLogLevel</key></div><div class=""> <string>warn</string> <!-- debug, info, warn, error --></div><div class=""><br class=""></div></div></div></div></blockquote><br class=""></div><div class="">Nobody any idea on that ?</div></div></div></blockquote><br class=""></div><div>Hi,</div><div><br class=""></div><div>I suspect this is related to the import ordering / race condition that you've noticed in the past. Is it still the case that the calendar server command line tools don't work in the freebsd CS port?</div><div><br class=""></div><div>I had a VM with this partially set up, but I banged on it enough last week that I sort of forget where it's at. Currently, attempts to "pkg install py27-calendarserver-9.0" yield a CS installation that is pretty broken:</div><div><br class=""></div><div>[cs@ ~]$ calendarserver_config -h<br class="">Traceback (most recent call last):<br class=""> File "/usr/local/bin/calendarserver_config", line 6, in <module><br class=""> from pkg_resources import load_entry_point<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3019, in <module><br class=""> @_call_aside<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside<br class=""> f(*args, **kwargs)<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set<br class=""> working_set = WorkingSet._build_master()<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 657, in _build_master<br class=""> return cls._build_from_requirements(__requires__)<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 670, in _build_from_requirements<br class=""> dists = ws.resolve(reqs, Environment())<br class=""> File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 849, in resolve<br class=""> raise DistributionNotFound(req, requirers)<br class="">pkg_resources.DistributionNotFound: The 'Twisted==15.4.0' distribution was not found and is required by CalendarServer</div><div><br class=""></div><div>... and if I explicitly install Twisted 15.4.0, the CLI tools work at least. Try this:</div><div><br class=""></div><div>[cs@ ~]$ calendarserver_config DefaultLogLevel<br class="">DefaultLogLevel=warn</div><div><br class=""></div><div>The above should be similar to what the server actually does to obtain config values. If I change DefaultLogLevel in /usr/local/etc/caldavd.plist, that change is reflected by calendarserver_config.</div><div><br class=""></div><div>Also, can you share the command you use to actually start CS? I never invoke caldavd directly, and CS changes its process name after launch so you can't just look at it, and newproc.d on OS X will show you processes names and launch args, but not ALL of the args... All my attempts seem to result in:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>/usr/local/bin/twistd: Unknown command: caldav</div><div>... but I'm surely doing it wrong.</div><div><br class=""></div><div>•</div><div><br class=""></div><div>What I want to try is getting CS to run in the 'developer mode' from a git checkout, using the bin/run script. In that state, the location and import order of all the modules should be fairly predictable, and I suspect that might be enough to get the config to load as expected. But, I still have to wade through a bunch of broken stuff to get ./bin/develop to run cleanly. There are some aspects of the ./bin/develop script (and the scripts it sources) that just don't work very well on BSD.</div><div><br class=""></div><div>-dre</div></body></html>