[systemd-devel] [PACKAGERS] rsyslog and systemd

[Andrey Borzenkov]

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.
>
> 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?