On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev <mk.frag...@gmail.com> wrote: > On Fri, 11 Mar 2011 16:55:28 +0100 > Lennart Poettering <lenn...@poettering.net> wrote: > >> On Fri, 11.03.11 09:15, Mike Kazantsev (mk.frag...@gmail.com) wrote: >> >> > On Mon, 7 Mar 2011 23:49:45 +0100 >> > Lennart Poettering <lenn...@poettering.net> wrote: >> > >> > > Heya, >> > > >> > > in the past weeks a couple of folks have been asking about the rsyslog >> > > and systemd glue in systemd, and I never responded since this was still >> > > work in progress. Things should be all resolved now, so here's a >> > > heads-up in how things should work now: >> > > >> > > I have just sent a patch to rsyslog upstream: >> > > >> > > http://0pointer.de/public/0001-systemd-use-standard-syslog.socket-unit.patch >> > >> > Is there any reason why it resorts to "ExecStartPre=/bin/systemctl >> > stop ..." instead of just using "Conflicts=systemd-kmsg-syslogd.service"? >> > >> > Both seem to equally work for me, but I wonder if there's some subtle >> > pitfall in Conflicts= for this case, so you avoid to use it. >> >> They do different things. >> >> The bootup transaction covers the entire boot. If you use Conflicts= >> then only one of the to syslog implementations can be part of it, and >> the other is removed. However we want both syslogs to be part of the >> transaction, and both started, one during early boot and one during late >> boot. Hence we allow both in the transaction, but modify the transaction >> later on when rsyslog is ready to start. > > Understood. > > Still, syslog.socket is the thing that gets into a bootup transaction, > not the systemd-kmsg-syslogd.service, right? > Guess the latter just won't be started as long as rsyslog.service > hangs in the jobs queue, produced by that transaction. >
But then it won't be stopped either as Conflicts covers only initial transaction creation. It does not mean "stop other service when this one is started". Unfortunately :) > Btw, rsyslog.service seem to be installed into multi-user.target.wants, > why not syslog.target, which seem to indicate the point where proper > syslog daemon is running (according to systemd.special(7))? > Actually good question (same as for portmap) - who should pull in syslog.target then? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel