Python daemon ate my syslog message

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.

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.

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)

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.

Why not just log to stderr?