On Wed, 14 Aug 2019 at 10:26:53 -0400, Brian Reichert wrote: > And, if I were to ever use daemonize(1), or any other other canonical > mechanism for daemonizing code, STDOUT would normally be closed > under those circumstances, as well.
Doesn't daemonize(1) make stdin, stdout and stderr point to /dev/null, instead of closing them? That's what glibc daemon(3) does, and seems a lot better as a way to not break subprocesses' expectations. The man pages of the daemon(1) and daemonize(1) in Debian also both say they do this, and it's what is recommended in systemd's own daemon(7). Expecting arbitrary subprocesses to cope gracefully with being invoked without the three standard fds seems likely to be a losing battle. I've implemented this myself, in dbus; it isn't a whole lot of code, but it also isn't something that I would expect the authors of all CLI tools to get right. dbus only does this because X11 autolaunching can lead to dbus-daemon being invoked in a broken execution environment, and I would have considered the equivalent bug in most tools to be WONTFIX. Expecting arbitrary *library code* to cope gracefully with being invoked without the three standard fds seems like a non-starter, because these fds are process-global state, so library code cannot safely mess with them unless specifically asked to do so by the calling process. In general library code can't do this safely anyway, because as soon as the process has a second thread, it becomes impossible to fix the fds in one thread without risking breaking another thread - this is one of the operations that is usually only safe to do right at the beginning of main(), similar to setenv(). smcv  I'm sure there are lots of other executables named daemon or daemonize in other OSs, and perhaps some of them get this wrong? _______________________________________________ systemd-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel