[systemd-devel] [PACKAGERS] rsyslog and systemd
arvidjaar at mail.ru
Fri Mar 11 10:20:50 PST 2011
On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev <mk.fraggod at gmail.com> wrote:
> On Fri, 11 Mar 2011 16:55:28 +0100
> Lennart Poettering <lennart at poettering.net> wrote:
>> On Fri, 11.03.11 09:15, Mike Kazantsev (mk.fraggod at gmail.com) wrote:
>> > On Mon, 7 Mar 2011 23:49:45 +0100
>> > Lennart Poettering <lennart at 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.
> 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
More information about the systemd-devel