On 13/06/2015 21:46, Steve Litt wrote:
> When I write my own daemons (for use with daemontools,
> daemontools-encore, runit, and soon to be S6), I use stdout to write to
> the log. Wouldn't the writenewline/close interfere with that?
It's more idiomatic to actually use stderr to write to the log.
stderr is traditionally "the place where I write diagnostic
messages for an external observer", and stdout is traditionally
"the place where I write stuff as a part of my workflow".
Logs fall in the former category, not in the latter; and daemons
usually have no use for stdout. You could arguably call it a
misdesign in daemontools (repeated in runit and s6) that the
logging pipe is tied to the daemon's stdout, not its stderr, by
default; fortunately, it's very easy to fix in the run script.
Almost all of my run scripts start with "fdmove -c 2 1", which
redirects stdout to stderr (the shell equivalent would be
"exec 2>&1"). That's the behaviour I would also recommend for
your daemons.
That said, sdnotify-wrapper, as well as s6-notifywhenup, comes
with a "-d" option that allows you to choose what descriptor
the notification will be read on. So if you're dead set on
logging to stdout, you can write your readiness newline to
descriptor 3, for instance, and document this; the admin wanting
to run your daemon will simply give the "-d 3" option to the
wrapper.
> How do I take advantage of sdnotify-wrapper if I'm using S6?
You don't use sdnotify-wrapper, because you're already using
a kickass supervision suite and have no need for crutches. :)
> How do I take advantage of sdnotify-wrapper if I'm using
> daemontools-encore?
You don't. You only use sdnotify-wrapper if you're an
administrator using systemd to manage a daemon that refuses to
use sd_notify() and uses the "write a newline to a file
descriptor" notification mechanism instead.
The point of the wrapper is to prevent having to include
systemd code in the daemon's code to make it systemd-compatible.
If you've never been tempted to use sd_notify() in the code you
write, and if you are not using systemd as a supervision
framework, then you can quietly ignore everything about it. :)
--
Laurent
Received on Sat Jun 13 2015 - 20:35:13 UTC