On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work

[pbloom]

BPO	46914
Nosy	@vsajip, @ronaldoussoren, @ned-deily

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-03-03.20:07:57.154>
labels = ['OS-mac', 'type-bug', '3.8', '3.9', '3.10', '3.7']
title = 'On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work'
updated_at = <Date 2022-03-04.21:59:33.393>
user = 'https://bugs.python.org/pbloom'

bugs.python.org fields:

activity = <Date 2022-03-04.21:59:33.393>
actor = 'pbloom'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['macOS']
creation = <Date 2022-03-03.20:07:57.154>
creator = 'pbloom'
dependencies = []
files = []
hgrepos = []
issue_num = 46914
keywords = []
message_count = 5.0
messages = ['414464', '414469', '414505', '414506', '414552']
nosy_count = 4.0
nosy_names = ['vinay.sajip', 'ronaldoussoren', 'ned.deily', 'pbloom']
pr_nums = []
priority = 'normal'
resolution = 'third party'
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46914'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10']

[pbloom]

Hello, don't file these often so apologies for any mistakes, trying to be good python citizen here.

Checked this on the python-list first, and others reported it as reproducible.

The issue is:
On Osx Monterey(12.x), Logging.handlers.SysLogHandler does not work. It won't throw any error but the ASL/Console.App does not see any messages from it. On OSX Big Sur (11.x) this works just fine with the exact same code.

I think I've cut this into a small example proof that can be run to demonstrate the issue. If this is run and any of the substrings are searched for in Console.App when it is checking events, only the QQQ message from SysLog will show up.

Gonna work around it likely on our end, but hope this helps it get fixed for a future version.

---

import logging
from logging.handlers import SysLogHandler

root_logger = logging.getLogger()
root_logger.setLevel(logging.DEBUG)
basic_datefmt = '%m/%d/%Y %I:%M:%S %p'

syslog_format = logging.Formatter(fmt='SetupCDNGUI: %(message)s', datefmt=basic_datefmt)

sys_handler = SysLogHandler(address='/var/run/syslog')
#sys_handler.encodePriority(SysLogHandler.LOG_USER, SysLogHandler.LOG_ALERT)
# Tried with the above, but didn't make a difference.  Neither did not defining the address and letting it go to local host.
sys_handler.setFormatter(syslog_format)
root_logger.addHandler(sys_handler)


# None of these will show up.
logging.critical("CCC This is a test critical")
logging.error("EEE This is a test error")
logging.info("III Still a test")


# Comparatively this sends a message received just fine
import syslog

syslog.openlog(logoption=syslog.LOG_PID, facility=syslog.LOG_USER)
syslog.syslog(syslog.LOG_NOTICE, 'QQQ test log')

[ronaldoussoren]

This is probably not a bug in python, but a change in system behaviour.

In particular, I've used the lsof command to check the open files for the syslogd proces on a macOS 10.13 and 12.2 system. On the former syslogd has /var/run/syslog open, on the latter it doesn't.

The feature to listen on this socket has been removed entirely, the 12.2 system no longer lists a "-bsd_in" option for syslogd in the manual page whereas it is both available and enabled by default on 10.13.

It might be possible to change the SyslogHandler to optionally use the syslog module to log, but I'm not sure it is worth doing this and that would definitely be a new feature.

[pbloom]

I could certainly understand that. It's a weird apple choice.

If so, then it probably good to adjust https://docs.python.org/3/library/logging.handlers.html#sysloghandler since it still talks about it being expected.

[vsajip]

If so, then it probably good to adjust ... since it still talks about it being expected.

Do you mean just adding a note to the effect that SysLogHandler won't work on macOS 12.2 because of changes to the syslog daemon on that platform?

IIRC using the syslog module was not an option at the time SysLogHandler was added, I think because of both thread-safety and lack-of-functionality issues.

[pbloom]

Do you mean just adding a note to the effect that SysLogHandler won't work on macOS 12.2 because of changes to the syslog daemon on that platform?

Yes or removing the specific guidance about OSX handling on it, mostly just to reduce folks coming to ask as they transition to it. That way it comes off that you need to provide a Syslog consumer to use the handler/not to expect one to exist on the platform. Hope I'm phrasing that understandably.

[Mausy5043]

And (maybe?) point macOS users to alternative methods or workarounds?