On Wed, Mar 16, 2011 at 1:23 PM, Michael Biebl <mbi...@gmail.com> wrote: > 2011/3/16 Andrey Borzenkov <arvidj...@mail.ru>: >> On Wed, Mar 16, 2011 at 1:00 PM, Andrey Borzenkov <arvidj...@mail.ru> wrote: >>> On Wed, Mar 16, 2011 at 11:28 AM, Michael Biebl <mbi...@gmail.com> wrote: >>>> 2011/3/12 Andrey Borzenkov <arvidj...@mail.ru>: >>>>> >>>>> 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 >>>> >>>> Some thougths: >>>> >>>> - What happens if you have multiple services providing that functionality? >>>> Is then foo.target considered started when any or all of those services >>>> are up? >>> >>> if every service has Before=foo.target - all of them. If services do >>> not have Before=foo.target - it does not matter who pulls in who. >>> >>>> - What happens if you have a service foo.service that "provides" >>>> bar.target, but also a symlink in bar.target.wants/baz.service? >>> >>> Service will be started even if it is deactivated (i.e. systemctl >>> disable/chkconfig off). >> >> >> Oops, old habits die slowly :) Of course "systemctl disable" will >> remove this link. So to answer - if foo.service is WnatedBy >> foo.target, it will *additionally* be started if foo.target is >> requested to start. Whether foo.service will be started *before* or >> *after* foo.target is controller by Before/After, which is rather >> orthogonal to activation trigger. >> >>> >>>> - What if you have a target, say samba.target, which needs to start >>>> multiple services, say nmb.servic, smbd.service etc? >>>> >>> >>> So let samba.target pull in those services. Where is the problem? >>> >>>> Basically, your suggestions only works if you only ever have one >>>> service that provides the "functionality". >>>> >>> >>> What gives you this impression? >>> >>> My suggestion ensures that *if* foo.service that provides >>> functionality of foo.target is started *then* foo.target is really >>> available. Nothing more nothing less. You can continue to pull in >>> foo.service from foo.target as before. But you already have seen how >>> confusing it is for administrators. And - how do you decide which >>> target should pull in e.g. rpcbind.target? You add yet another layer >>> of indirection for sysadmin to control. My suggestion simply lessen >>> learning's curve by ensuring things "just work" > > Sorry, but your proposal is stil unclear to me. > How do describe that e.g. rsyslog.service "provides" syslog.target? > Do you want to introduce a new Keyword like Provides=syslog.target > that needs to be added to the rsyslog.service unit file?
No. rsyslog.service should have Wants=syslog.target Before=syslog.target This ensures that - if rsyslog.service is started syslog.target will be started also - syslog.target will become Active only after rsyslog.service has completed startup. This ensures that any service that specified After=syslog.target will be started only after rsyslog.service is started. For socket activation we would add Wants=syslog.target to rsyslog.socket, as this is the point where syslog functionality becomes available. > Or is rsyslog expected to provide a symlink in syslog.target.wants? > This is really orthogonal. As Lennart commented, it may be sensible to do both. But this symlink does not ensure syslog is actually started before syslog.target. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
