On Sat, 12.03.11 13:00, Andrey Borzenkov ([email protected]) wrote: > On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl <[email protected]> wrote: > > 2011/3/12 Michael Biebl <[email protected]>: > >> 2011/3/11 Andrey Borzenkov <[email protected]>: > >>> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev <[email protected]> > >>> wrote: > >> > >>> > >>>> 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? > >> > >> 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. > > > > The problem is not limited to syslog and applies to all special > targets that serve as "virtual provides" > > Actually I think design should be reversed. The service that > implements this virtual provide (syslog, network, rpcbind, smtp, ...) > should pull in special target. This way you ensure
Hmm, interesting idea. I wonder though if we might want to go even one step further: make the .target unit Want the .service unit and vice versa, too; but order the .target unit after the .service unit. That way, starting rsyslog.service will pull up syslog.target, but pulling up the latter will also start rsyslog.service. I need to think about this... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
