On 17/11/14 19:20, Anthony Towns wrote:
> Where possible, units should not use Type=forking or PIDFile,
> but instead should invoke daemons with options
> that tell them to remain in the foreground. This allows
> systemd to provide better monitoring of the process.
I understand what you're trying to say, but I think a maintainer in a
hurry could easily read this as "oh, I should prefer to use
Type=simple?" which is usually wrong. The desired situation is
* if readiness notification is desirable (i.e. anything could
reasonably depend on this daemon having fully started - usually true):
* if notify is possible: use it
* else if dbus readiness notification is possible and the daemon
depends on dbus anyway: use it
* else if forking is possible: use it
* [... give up, you've run out of notification schemes, AIUI]
* else:
* any startup notification scheme will do, including none
Perhaps something like this?
"""
However, if the other mechanisms by which systemd can determine when the
daemon has become ready are not available or suitable, Type=forking
should be used.
"""
> If the daemon has options to output useful logging information on
> standard output and/or standard error, these should be enabled.
Logging to the Journal directly via libsystemd APIs would also be OK,
and is the best way if the daemon supports it (it captures the maximum
possible amount of metadata). Some daemons automatically do this if they
detect that pid 1 is systemd.
Logging to /dev/log, via syslog() or equivalent, would also be OK;
systemd can capture a smaller amount of metadata that way (notably,
messages' priority levels).
I think logging normal activity to stdout/stderr should be a last resort
if neither Journal- or syslog-based logging is available.
If the daemon would log duplicate messages to std{out,err} and syslog
(e.g. LOG_PERROR), it should be told to log to one or the other but not
both. Worst case, it can be configured to log to both and the unit can
have StandardWhatever=null, but the reason that that is the worst case
is that it would also suppress warnings to stderr that are not
integrated with the daemon's logging, such as the warnings libc prints
just before aborting when it detects heap corruption.
Some daemons automatically suppress duplicate messages under systemd - I
am aware of at least dbus-daemon, which turns off LOG_PERROR under
systemd to avoid this duplication.
> Units should use socket and/or bus activation wherever possible
For bus activation, the package will need to depend on dbus. I hope
that's obvious, but it should probably be stated :-)
S
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546a7269.8070...@debian.org
