On 2022-03-05 16:25:38 +0000, Barry Scott wrote: > On 4 Mar 2022, at 21:23, Peter J. Holzer <hjp-pyt...@hjp.at> wrote: > > If you are saying that SysLogHandler should use a system specific > > default (e.g. "/dev/log" on Linux) instead of UDP port 514 everywhere, I > > agree 99 % (the remaining 1 % is my contrarian alter ego arguing that > > that's really the distribution maintainer's job since a Linux > > distribution might use some other socket). > > > > If you are saying it should use the libc syslog routines, I disagree for > > at least two reasons: a) they are OS specific, b) you can't configure the > > destination. So that would remove useful functionality. > > > > In any case it seems strange to me that you want to rewrite it just to > > avoid passing a single parameter to the constructor (or - more likely - > > adding a single line to a config file). > > What I am used to is a setup where programs use syslog() to log and > a dameon like rsyslog is responsible for routing the logs to local files > and/or remote systems.
Yes, that's a pretty common setup.
> On a modern linux I think the route is syslog() -> journald. And you
> can have syslog() -> journald -> rsyslogd.
Yes. Journald accepts syslog (RFC 5424) protocol on /dev/log and can
optionally forward messages to another syslog daemon (but only via Unix
sockets, AFAICS, not via UDP or TCP). rsyslog is then configured to
accept those forwarded messages (and may also be configured to accept
messages on port 514, but this isn't the case by default on Debian or
Ubuntu).
> Using the syslog() function means that any platform/distro details are
> hidden from the user of syslog() and as is the case of macOS it
> "just works".
That doesn't seem to be case. Philip Bloom reported in
<CADoNktVgU9DBdBfc5wJe4vhJcTKrdVQjdeUO8eN=bvtw9g4...@mail.gmail.com>,
that syslog in Python 3.6 broke in OS X Monterey. So even using
syslog(3) doesn't seem to be safe across upgrades (no, I don't know
how Apple managed to break this - as I wrote, I don't use OS X).
> (I assume, not checked, that the write to the socket does not work
> because Apple is not implementing the syslog protocol from the RFC).
>
> >
> >> What you do not see used in the SyslogHandler() is the import syslog
> >> and hence its nor using openlog() etc from syslog API.
> >
> > For good reasons. The C syslog API is missing important functionality.
>
> What are you think about being missing? Just curious.
As I already wrote:
* System independence. The libc syslog(3) function (and the Python
syslog package using it) exists only on Unix-like OSs. Not Windows.
Probably not some embedded platforms. SyslogHandler works on all
platforms with networking.
* Configurable targets. The SyslogHandler allows you to specify where to
send the messages. syslog(3) does not. So with syslog(3) you always
need a locally running daemon. In containers or embedded systems this
might add extra unnecessary complexity.
> As an aside if I had the need to log into a system log mechanism I'd be
> looking to use the jounald API so that I can use structured logging on linux
> systems.
That might be useful. Journald already adds a bit of extra information
to messages received over the syslog, but using the API directly would
probably give the user more control.
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
