LogLevels does not work on 9.0
Hi, setting <key>LogLevels</key> <dict> <key>twistedcaldav.memcachepool</key> <string>info</string> <key>twistedcaldav.memcacher</key> <string>info</string> <key>twext.enterprise.adbapi2</key> <string>info</string> </dict> does not stop the chatty logging like [twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'jobqueue.workCheck': free=2, busy=0, waiting=0 [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy 'jobqueue.workCheck': free=1, busy=1, waiting=0 [caldav-0] [twistedcaldav.memcachepool.MemCachePool#debug] Freed client: <twistedcaldav.memcachepool.PooledMemCacheProtocol instance at 0x80de7ee60> [caldav-0] [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 1, #busy: 0, #pending: 0, #queued: 0 [caldav-0] [twistedcaldav.memcacher.Memcacher#debug] Getting Cache Token for u’2191/some_user' Any hints wellcome, Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Do you by chance have the default log level set to debug? I still think a more specific entry from LogLevels should override the default, whether it is higher or lower, but maybe it only works to raise verbosity (which is how we use it). -dre
On Dec 17, 2016, at 4:39 AM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Hi,
setting
<key>LogLevels</key> <dict> <key>twistedcaldav.memcachepool</key> <string>info</string> <key>twistedcaldav.memcacher</key> <string>info</string> <key>twext.enterprise.adbapi2</key> <string>info</string> </dict>
does not stop the chatty logging like
[twext.enterprise.adbapi2#debug] ConnectionPool: txn free 'jobqueue.workCheck': free=2, busy=0, waiting=0 [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy 'jobqueue.workCheck': free=1, busy=1, waiting=0
[caldav-0] [twistedcaldav.memcachepool.MemCachePool#debug] Freed client: <twistedcaldav.memcachepool.PooledMemCacheProtocol instance at 0x80de7ee60> [caldav-0] [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 1, #busy: 0, #pending: 0, #queued: 0 [caldav-0] [twistedcaldav.memcacher.Memcacher#debug] Getting Cache Token for u’2191/some_user'
Any hints wellcome, Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
Am 18.12.2016 um 00:35 schrieb Andre LaBranche <dre@apple.com>:
Do you by chance have the default log level set to debug? No it is set to ‚warn‘:
<key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error --> Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Am 18.12.2016 um 14:01 schrieb Axel Rau <Axel.Rau@chaos1.de>:
Am 18.12.2016 um 00:35 schrieb Andre LaBranche <dre@apple.com <mailto:dre@apple.com>>:
Do you by chance have the default log level set to debug? No it is set to ‚warn‘:
<key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error -->
Nobody any idea on that ? Produces 10MB/day. Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
On Jan 21, 2017, at 3:43 AM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Am 18.12.2016 um 14:01 schrieb Axel Rau <Axel.Rau@chaos1.de <mailto:Axel.Rau@chaos1.de>>:
Am 18.12.2016 um 00:35 schrieb Andre LaBranche <dre@apple.com <mailto:dre@apple.com>>:
Do you by chance have the default log level set to debug? No it is set to ‚warn‘:
<key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error -->
Nobody any idea on that ? Produces 10MB/day.
Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
Do you have anything set in the LogLevels dict (which overrides DefaultLogLevel for the specified modules)? What warnings/errors are you seeing?
Am 21.01.2017 um 21:07 schrieb Morgen Sagen <sagen@apple.com>:
Do you have anything set in the LogLevels dict (which overrides DefaultLogLevel for the specified modules)? Not I. Your released software has some modules with debug turned on. To workaround that, I would have to add patches to the FreeBSD port of calendarserver, I maintain, which I do not like. What warnings/errors are you seeing? [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 0, #busy: 1, #pending: 0, #queued: 0 [twistedcaldav.cache.MemcacheResponseCache#debug] Checking cache for: u’b198c4f70e75b5d2dfec1291599d4e10' [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 0, #busy: 1, #pending: 0, #queued: 0 [txdav.who.cache#debug] Directory cache hit: [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy [txdav.base.datastore.util.QueryCacher#debug] Getting Cache Token for [txdav.who.groups.GroupCacher#debug] There are 0 group sharees
Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
On Jan 22, 2017, at 3:30 AM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Am 21.01.2017 um 21:07 schrieb Morgen Sagen <sagen@apple.com <mailto:sagen@apple.com>>:
Do you have anything set in the LogLevels dict (which overrides DefaultLogLevel for the specified modules)? Not I. Your released software has some modules with debug turned on.
Which plist in the git repo are you referring to? https://github.com/apple/ccs-calendarserver/blob/CalendarServer-9.0/conf/cal... <https://github.com/apple/ccs-calendarserver/blob/CalendarServer-9.0/conf/caldavd-test.plist> does not have any debug logging active.
To workaround that, I would have to add patches to the FreeBSD port of calendarserver, I maintain, which I do not like.
What warnings/errors are you seeing? [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 0, #busy: 1, #pending: 0, #queued: 0 [twistedcaldav.cache.MemcacheResponseCache#debug] Checking cache for: u’b198c4f70e75b5d2dfec1291599d4e10' [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 0, #busy: 1, #pending: 0, #queued: 0 [txdav.who.cache#debug] Directory cache hit: [twext.enterprise.adbapi2#debug] ConnectionPool: txn busy [txdav.base.datastore.util.QueryCacher#debug] Getting Cache Token for [txdav.who.groups.GroupCacher#debug] There are 0 group sharees
Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
Am 22.01.2017 um 19:40 schrieb Morgen Sagen <sagen@apple.com>:
On Jan 22, 2017, at 3:30 AM, Axel Rau <Axel.Rau@Chaos1.DE <mailto:Axel.Rau@Chaos1.DE>> wrote:
Am 21.01.2017 um 21:07 schrieb Morgen Sagen <sagen@apple.com <mailto:sagen@apple.com>>:
Do you have anything set in the LogLevels dict (which overrides DefaultLogLevel for the specified modules)? Not I. Your released software has some modules with debug turned on.
Which plist in the git repo are you referring to?
https://github.com/apple/ccs-calendarserver/blob/CalendarServer-9.0/conf/cal... <https://github.com/apple/ccs-calendarserver/blob/CalendarServer-9.0/conf/caldavd-test.plist> does not have any debug logging active.
I will look at that. All what I have is : <!-- Logging --> <!-- Log root --> <key>LogRoot</key> <string>/var/log/caldavd</string> <!-- Apache-style access log --> <key>AccessLogFile</key> <string>access.log</string> <key>RotateAccessLog</key> <true/> <!-- Server activity log --> <key>ErrorLogFile</key> <string>error.log</string> <!-- Log levels --> <key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error --> <!-- Allows overriding log levels on a per-package, per-module, or even per- class basis --> <key>LogLevels</key> <dict> <key>twistedcaldav.memcachepool</key> <string>info</string> <key>twistedcaldav.memcacher</key> <string>info</string> <key>twext.enterprise.adbapi2</key> <string>info</string> </dict> The LogLevels block was a workaround attempt. Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
On Jan 21, 2017, at 3:43 AM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Am 18.12.2016 um 14:01 schrieb Axel Rau <Axel.Rau@chaos1.de <mailto:Axel.Rau@chaos1.de>>:
Am 18.12.2016 um 00:35 schrieb Andre LaBranche <dre@apple.com <mailto:dre@apple.com>>:
Do you by chance have the default log level set to debug? No it is set to ‚warn‘:
<key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error -->
Nobody any idea on that ?
Hi, 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? 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: [cs@ ~]$ calendarserver_config -h Traceback (most recent call last): File "/usr/local/bin/calendarserver_config", line 6, in <module> from pkg_resources import load_entry_point File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3019, in <module> @_call_aside File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside f(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 657, in _build_master return cls._build_from_requirements(__requires__) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 670, in _build_from_requirements dists = ws.resolve(reqs, Environment()) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 849, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'Twisted==15.4.0' distribution was not found and is required by CalendarServer ... and if I explicitly install Twisted 15.4.0, the CLI tools work at least. Try this: [cs@ ~]$ calendarserver_config DefaultLogLevel DefaultLogLevel=warn 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. 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: /usr/local/bin/twistd: Unknown command: caldav ... but I'm surely doing it wrong. • 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. -dre
Hi Andre,
Am 25.01.2017 um 02:01 schrieb Andre LaBranche <dre@apple.com>:
On Jan 21, 2017, at 3:43 AM, Axel Rau <Axel.Rau@Chaos1.DE <mailto:Axel.Rau@Chaos1.DE>> wrote:
Am 18.12.2016 um 14:01 schrieb Axel Rau <Axel.Rau@chaos1.de <mailto:Axel.Rau@chaos1.de>>:
Am 18.12.2016 um 00:35 schrieb Andre LaBranche <dre@apple.com <mailto:dre@apple.com>>:
Do you by chance have the default log level set to debug? No it is set to ‚warn‘:
<key>DefaultLogLevel</key> <string>warn</string> <!-- debug, info, warn, error -->
Nobody any idea on that ?
Hi,
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?
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:
[cs@ ~]$ calendarserver_config -h Traceback (most recent call last): File "/usr/local/bin/calendarserver_config", line 6, in <module> from pkg_resources import load_entry_point File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3019, in <module> @_call_aside File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3003, in _call_aside f(*args, **kwargs) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3032, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 657, in _build_master return cls._build_from_requirements(__requires__) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 670, in _build_from_requirements dists = ws.resolve(reqs, Environment()) File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 849, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The ‚Twisted==15.4.0' distribution was not found and is required by CalendarServer
The package www/calendarserver currently installs twisted 16.6.0, and that works. One of the reasons, I never got the commandline tools working are those hard wired dependencies. Would 16.6.0 not work with them?
... and if I explicitly install Twisted 15.4.0, the CLI tools work at least. Try this:
[cs@ ~]$ calendarserver_config DefaultLogLevel DefaultLogLevel=warn
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.
Also, can you share the command you use to actually start CS?
If you install the package, its in /usr/local/etc/rc.d/caldavd .
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: /usr/local/bin/twistd: Unknown command: caldav … but I'm surely doing it wrong.
[caldav3:/] root# service caldavd onestart Starting caldavd. Reading configuration from file: /usr/local/etc/caldavd/caldavd.plist [caldav3:/] root# service caldavd onestatus caldavd is running as pid 10762. [caldav3:/] root# ps -axlww | grep CalendarServer 0 10762 1 0 20 0 224484 94564 kqread SJ - 0:02.22 python2.7: CalendarServer Combined (python2.7) 639 10764 10762 0 20 0 219220 90872 kqread SJ - 0:06.74 python2.7: CalendarServer Directory Proxy Service (python2.7) 639 10765 10762 0 20 0 232172 97156 kqread SJ - 0:08.22 python2.7: CalendarServer Slave #0 (python2.7) 639 10766 10762 0 20 0 231024 95332 kqread IJ - 0:07.97 python2.7: CalendarServer Slave #1 (python2.7) 0 10817 10689 0 20 0 14796 2472 - R+J 2 0:00.00 grep CalendarServer [caldav3:/] root#
•
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.
Yes. I’m no expert in ports and pkg. Perhaps you get some insight here https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-pyt... <https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-python.html> The port is based on this makefile: https://svnweb.freebsd.org/ports/head/www/calendarserver/Makefile?revision=4... <https://svnweb.freebsd.org/ports/head/www/calendarserver/Makefile?revision=428900&view=markup> I’m currently quite busy, but could allocate more time to this next week. Axel --- PGP-Key:29E99DD6 ☀ computing @ chaos claudius
participants (4)
-
Andre LaBranche
-
Axel Rau
-
Axel Rau
-
Morgen Sagen