
Python daemon ate my syslog message - fanf2
http://prgmr.com/blog/2020/08/29/python-ate-my-log-message.html
======
JdeBP
Ironically, this is yet another example of why "dæmonization" is a fallacy.
Closing all open file descriptors broke the library code that was using a
private file descriptor to send things to the syslog server. It breaks that,
other forms of logging, and indeed other library functions that might hold on
to private file descriptors for whatever reason.

Had one thrown away the fallacious idea that one has to, _or even can_ ,
"dæmonize" from a login session context to a dæmon context, this entire
problem wouldn't have arisen, irrespective of whether one logged to syslog or
to standard error (which is another factor in its own right).

It looks like daemon.DaemonContext() is the function to recommend avoiding
here, not just os.close() of arbitrary file descriptors.

------
db48x
A fun bug to track down, I'm sure. Personally I would prefer not to daemonize
by forking, but instead set up a systemd unit for the service. The program
will be simpler, and administrating it will be simpler too.

------
theamk
Wrong title: it was not python, it was third-party “daemon” package.

Closing random file descriptors in complex systems is extremely dangerous
practice, and I had to debug the same bugs in C++ programs as well.

(The ancient advice to close all file descriptors on demonization only applies
to simpler programs where the programmer knows each file descriptor used. Once
third-party libraries come into play, this is no longer safe)

------
sn
This blog post has been changed to clarify the context for why daemonization
is in use (the service is very old, meaning it predates systemd) and also
gives an even more simple sample program that illustrates the underlying issue
without use of daemonization or syslog.

~~~
JdeBP
Pre-dating systemd is no excuse. People have been explaining not to do
"dæmonization" since 1995.

* [http://jdebp.uk./FGA/unix-daemon-design-mistakes-to-avoid.ht...](http://jdebp.uk./FGA/unix-daemon-design-mistakes-to-avoid.html#DoNotBackgroundise)

------
neolog
Why not just log to stderr?

~~~
db48x
If you just log to stderr, you must have some other system hanging around to
read that output and put it in the system log files for you. syslog doesn't do
that, but systemd does.

~~~
JdeBP
Such systems have been available on Linux-based operating systems since the
middle 1990s. It's not a new systemd thing by a long chalk.

* [http://jdebp.uk./FGA/daemontools-family.html#Logging](http://jdebp.uk./FGA/daemontools-family.html#Logging)

~~~
db48x
Of course, I didn't say otherwise.

