On 14/06/13 12:54, Dmitrijs Ledkovs wrote:
> On 14 June 2013 12:49, Simon McVittie <s...@debian.org> wrote:
>> Similarly, if you disable or alter the pidfile in the XML, sysvinit
>> and Upstart are not going to work correctly.
>
> Upstart doesn't track pidfiles at all. At the moment it's set to fork,
> but could as well use --nofork & --nopidfile, for what performance
> boosts its worth.
> And upstart would then properly collect stdout/stderr into a logfile
> under /var/log/upstart/dbus.log.
Ah, OK... I'd assumed you wouldn't have used forking/pidfile unless you
needed to do so. That does seem nicer - the systemd unit collects
stdout/stderr too, although it puts them in the Journal/syslog instead
of its own file. (At the moment "stdout/stderr" mostly means the
stdout/stderr of bus-activated system services, since dbus-daemon uses
syslog anyway.)
If dbus doesn't fork, how does the Upstart job know that dbus is
actually ready for use and listening on its socket? Do I infer correctly
that the answer is "it doesn't"? That seems like a nasty race condition.
systemd doesn't need to know, because it uses socket activation, so
systemd is already listening-but-not-accepting on the socket. It's
unfortunate that Upstart seems to have its own flavour of socket
activation (pass one fd, put its number in $UPSTART_FDS) for which
dbus-daemon doesn't have upstream support. I'd review a patch upstream,
if desired (hint: it'd be remarkably similar to the "systemd:" code path
in dbus-sysdeps-unix.c.), although I'd prefer it if Upstart could learn
to do systemd-style LISTEN_FDS/LISTEN_PID so daemons didn't have to have
two pointlessly different code paths.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
