[systemd-devel] [PACKAGERS] rsyslog and systemd

Lennart Poettering lennart at poettering.net
Tue Mar 15 21:06:09 PDT 2011


On Fri, 11.03.11 23:10, 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?

It gets pulled in via:

/lib/systemd/system/sysinit.target.wants/systemd-kmsg-syslogd.service

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

Hmm, good question. Currently only syslog.socket is pulled in by
syslog.target. This should normally be enough I guess and we should keep
those meta-targets as small as possible I guess, to make bootup fast.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list