[systemd-devel] [PACKAGERS] rsyslog and systemd

Lennart Poettering lennart at poettering.net
Wed Mar 16 16:47:56 PDT 2011


On Wed, 16.03.11 07:17, Michael Biebl (mbiebl at gmail.com) wrote:

> >> > Yeah, I noticed this myself already. Quite a bit of syslog output
> >> > ended up in /proc/kmsg during boot because rsyslog was started rather
> >> > late (via multi-user.target).
> >> > Afaics, there is not explicit symlink pulling in syslog.target, so I
> >> > assume it is handled internally by systemd. Lennart?
> >>
> >> Turns out, that indeed syslog.target is not automatically started.
> >> I symlinked syslog.target into multi-user.target.wants and
> >> rsyslog.service into syslog.target.wants.
> >>
> >> Now all services with After=syslog.target are correctly started after
> >> rsyslog.service.
> >>
> >> Lennart, I think we should add those changes to systemd and rsyslog.service.
> >
> > I think we should pull in rsyslog.target by default, but I am not
> 
> Will that ensure that rsyslog is started before services using
> After=syslog.target?

No. Unless we do the second change.

> 
> > convinced that rsyslog.service should hook itself into syslog.target.
> >
> 
> What is syslog.target then good for?

if you pull that in you know that /dev/log can be written to. In case of
a socket activated syslog this means that if you pull that in you can
rely that the socket is established, but there's no guarantee that the
daemon is actually up. In case of a classic non-socket-activated syslog
this is more traditional however, and if syslog.target is reached then
syslog is completely running.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list