Logging hander using the syslog module

In #96339 I’ve proposed adding a new handler to the logging package that uses the syslog module to log. The primary reason for that proposal is that this allows logging to system logs on macOS.

In older versions of macOS it was possible to use SysLogHandler for this, but as #91070 notes that no longer works in macOS 12 because the logging daemon no longer listens on sockets (neither IP, nor Unix).

The syslog module still works, and adding a handler that uses it therefore makes it easier to keep logging to system logs on macOS. The same handler could also be used on other platforms, even if the need is less clear there.

@vsajip asked to start a topic here, hence this (belated) post. Any opinions on the usefulness of adding such a handler?


Would not it be just an alternate implementation of SysLogHandler? We do not need even a special name for it: if syslog works, use syslog-based implementation, otherwise fallback to using socket-based implementation. What can be wrong?

SysLogHandler can also log to different systems, by using a different address for the log server whereas the syslog module can only log to the local log destination.

It could be possible to only use a syslog based implementation when using the default address, but that would increase implementation complexity and can lead to changes in behaviour (especially when setting the “ident” (aka program name) for the handler: in SysLogHandler this a per-handler setting, in syslog(3) this is a global setting).

We use the syslog API at work and do now want to use the network API.

How would the logging.SysLogHandler() know to use the syslog API and not use the network API? Set address to None?


That’s one option. As mentioned earlier I’m slightly worried that this would lead to a more complicated implementation of SysLogHandler, although looking at the code again not by a lot: Basically the emit method would get a second path, with possibly some extra code to translate from the SysLogHandler.LOG_* constants to the same constants in syslog (The values likely are the same on all sane platforms, its probably better to assert this assumption in tests than introduce a conversion helper).

My proposal on GH is to introduce a new handler, but that leads to needing to find a good name, given that the most obvious one is already taken. I don’t particularly like my current attempt ( “LocalSysLogHandler”)

Local may be confused with localhost network logging.

SysLogApiHandler() or SysLogPlatformHandler() maybe?

Shame we cannot rename the existing handler to SysLogNetworkHandler().

SysLogHandler(address=None) might be workable. Now just to find some time to create a draft PR for this :wink:.