On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl <mbi...@gmail.com> wrote: > 2011/3/12 Michael Biebl <mbi...@gmail.com>: >> 2011/3/11 Andrey Borzenkov <arvidj...@mail.ru>: >>> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev <mk.frag...@gmail.com> >>> 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 - when service that provides functionality is started, corresponding virtual target is started as indication, that functionality is available - if there is no service with requested functionality, target is not available. In other words - target is not faked to be started unless functionality is available. This allows easy and logical check, whether syslog (rpcbind, network, ...) was really provided by any service - if unit is not started, it was not. To round this off, specials should also refuse manual activation. That does not apply to all specials; some of them do serve as "virtual requires" and pull in other services on demand. Think about bluetooth.target. Although (as Lennart replied regarding network) it should probably in reality be hci.tagret (or more generically - bt-device.target) rather than bluetooth.service, as it is exactly what we want to *pull* - specific driver for BT device. Which - in turn should pull in bluetooth.target as indication that BT is now available. Specials should really be generic statement "this functionality is now available". Not means to achieve this functionality. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel