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? Or is rsyslog expected to provide a symlink in syslog.target.wants? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel