Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Sat, Mar 12, 2011 at 1:00 PM, Andrey Borzenkov wrote: > On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl wrote: >> 2011/3/12 Michael Biebl : >>> 2011/3/11 Andrey Borzenkov : On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev 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. > Here is proof of concept patch. Notice that nfs fails utterly because it is started before rpc is ready without this patch (and yes, I know about socket activation for rpcbind, It is not the point here). rpcbind part is fixed by src/service.c patch. syslog part is fixed by addin Wants=syslog.target to rsyslog.service. Before [root@localhost ~]# systemctl --no-pager -p After -p Before -p Wants -p WantedBy -p Id show syslog.target rsyslog.service rpcbind.service rpcbind.target Id=syslog.target Wants= WantedBy= Before=dbus.service prefdm.service networkmanager.service acpid.service crond.service shorewall.service console-kit-daemon.service After=syslog.socket rsyslog.service Id=rsyslog.service Wants= WantedBy=multi-user.target Before=syslog.target shutdown.target After=local-fs.target basic.target Id=rpcbind.service Wants= WantedBy=rpcbind.target multi-user.target graphical.target Before=rpcbind.target shutdown.target multi-user.target graphical.target After=network.target basic.target Id=rpcbind.target Wants=rpcbind.service WantedBy= Before=netfs.service nfs-common.service After=rpcbind.service [root@localhost ~]# systemctl status syslog.target rsyslog.service rpcbind.service rpcbind.target syslog.target - Syslog Loaded: loaded (/lib/systemd/system/syslog.target) Active: inactive (dead) rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service) Active: active (running) since Sat, 12 Mar 2011 13:59:24 +0300; 1min 14s ago Process: 797 ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service (code=exited, status=0/SUCCESS) Main PID: 856 (rsyslogd) CGroup: name=systemd:/system/rsyslog.service └ 856 /sbin/rsyslogd -n -c 4 rpcbind.service - LSB: Start the rpcbind daemon Loaded: loaded (/etc/rc.d/init.d/rpcbind) Active: active (running) since Sat, 12 Mar 2011 13:59:30 +0300; 1min 8s ago Process: 1474 ExecStart=/etc/rc.d/init.d/rpcbind start (code=exited, status=0/SUCCESS) Main PID: 1499 (rpcbind) CGroup: name=systemd:/system/rpcbind.service └ 1499 rpcbind -i rpcbind.target - RPC Port Mapper Loaded: loaded (/lib/systemd/system/rpcbind.target)
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Sat, 12.03.11 13:00, Andrey Borzenkov (arvidj...@mail.ru) wrote: > On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl wrote: > > 2011/3/12 Michael Biebl : > >> 2011/3/11 Andrey Borzenkov : > >>> On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev > >>> 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
2011/3/16 Andrey Borzenkov : > On Wed, Mar 16, 2011 at 1:00 PM, Andrey Borzenkov wrote: >> On Wed, Mar 16, 2011 at 11:28 AM, Michael Biebl wrote: >>> 2011/3/12 Andrey Borzenkov : 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
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Wed, Mar 16, 2011 at 1:23 PM, Michael Biebl wrote: > 2011/3/16 Andrey Borzenkov : >> On Wed, Mar 16, 2011 at 1:00 PM, Andrey Borzenkov wrote: >>> On Wed, Mar 16, 2011 at 11:28 AM, Michael Biebl wrote: 2011/3/12 Andrey Borzenkov : > > 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
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > 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. Well, actually there is. If DefaultDependencies= is "yes" (which it is by default) for target units then they'll automatically gain an After= for all untis they have Wants= or Requires= on. (We currently do not document what DefaultDependencies= actually means for the specific unit types. We probably should...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 01:04:35 +0100 Lennart Poettering wrote: > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > 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. > > Well, actually there is. > > If DefaultDependencies= is "yes" (which it is by default) for target > units then they'll automatically gain an After= for all untis they have > Wants= or Requires= on. > > (We currently do not document what DefaultDependencies= actually means > for the specific unit types. We probably should...) > Can this behavior be relied upon or this might change in future releases? It's just that this magic bit makes After= line in lots of units I've seen (and wrote) redundant, so can it be dropped and skipped in any new units or it's better to be explicit in this case? -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 3:04 AM, Lennart Poettering wrote: > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > >> > 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. > > Well, actually there is. > > If DefaultDependencies= is "yes" (which it is by default) for target > units then they'll automatically gain an After= for all untis they have > Wants= or Requires= on. > yet another undocumented magic ... > (We currently do not document what DefaultDependencies= actually means > for the specific unit types. We probably should...) > Yes, please. BTW I remember there were other magic directories besides xxx.wanted, should not they be documented as well? Are they also handled by "systemctl enable/disable"? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev wrote: > On Thu, 17 Mar 2011 01:04:35 +0100 > Lennart Poettering wrote: >> If DefaultDependencies= is "yes" (which it is by default) for target >> units then they'll automatically gain an After= for all untis they have >> Wants= or Requires= on. > Can this behavior be relied upon or this might change in future > releases? > > It's just that this magic bit makes After= line in lots of units I've > seen (and wrote) redundant, so can it be dropped and skipped in any > new units or it's better to be explicit in this case? > Do you have that many target units? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 12:41:34 +0300 Andrey Borzenkov wrote: > On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev wrote: > > On Thu, 17 Mar 2011 01:04:35 +0100 > > Lennart Poettering wrote: > >> If DefaultDependencies= is "yes" (which it is by default) for target > >> units then they'll automatically gain an After= for all untis they have > >> Wants= or Requires= on. > > > Can this behavior be relied upon or this might change in future > > releases? > > > > It's just that this magic bit makes After= line in lots of units I've > > seen (and wrote) redundant, so can it be dropped and skipped in any > > new units or it's better to be explicit in this case? > > > > Do you have that many target units? Ah, I missed the "target units" part, but even then "Requires=network.target + After=network.target" is a common enough pattern for services that need network to be up at startup and After= line is present in each one of them: /lib/systemd/system/noip.service:Requires=network.target /lib/systemd/system/dnscache.service:Requires=network.target /lib/systemd/system/tinydns.service:Requires=network.target /lib/systemd/system/remote-fs.target:Requires=network.target /lib/systemd/system/ziproxy.service:Requires=network.target /lib/systemd/system/ejabberd.service:Requires=network.target /lib/systemd/system/dhcpd.service:Requires=network.target ... -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 1:59 PM, Mike Kazantsev wrote: > On Thu, 17 Mar 2011 12:41:34 +0300 > Andrey Borzenkov wrote: > >> On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev >> wrote: >> > On Thu, 17 Mar 2011 01:04:35 +0100 >> > Lennart Poettering wrote: >> >> If DefaultDependencies= is "yes" (which it is by default) for target >> >> units then they'll automatically gain an After= for all untis they have >> >> Wants= or Requires= on. >> >> > Can this behavior be relied upon or this might change in future >> > releases? >> > >> > It's just that this magic bit makes After= line in lots of units I've >> > seen (and wrote) redundant, so can it be dropped and skipped in any >> > new units or it's better to be explicit in this case? >> > >> >> Do you have that many target units? > > Ah, I missed the "target units" part, but even then > "Requires=network.target + After=network.target" is a common > enough pattern for services that need network to be up at startup and > After= line is present in each one of them: > Dependencies are added to target for units that it pulls. Not other way round. > /lib/systemd/system/noip.service:Requires=network.target > /lib/systemd/system/dnscache.service:Requires=network.target > /lib/systemd/system/tinydns.service:Requires=network.target > /lib/systemd/system/remote-fs.target:Requires=network.target > /lib/systemd/system/ziproxy.service:Requires=network.target > /lib/systemd/system/ejabberd.service:Requires=network.target > /lib/systemd/system/dhcpd.service:Requires=network.target I tentatively think that these should be either After or Requisite. Do you really want to start network every time one of those services gets started (assuming there were reasons to have network stopped at this moment)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 14:32:26 +0300 Andrey Borzenkov wrote: > On Thu, Mar 17, 2011 at 1:59 PM, Mike Kazantsev wrote: > > On Thu, 17 Mar 2011 12:41:34 +0300 > > Andrey Borzenkov wrote: > > > >> On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev > >> wrote: > >> > On Thu, 17 Mar 2011 01:04:35 +0100 > >> > Lennart Poettering wrote: > >> >> If DefaultDependencies= is "yes" (which it is by default) for target > >> >> units then they'll automatically gain an After= for all untis they have > >> >> Wants= or Requires= on. > >> > >> > Can this behavior be relied upon or this might change in future > >> > releases? > >> > > >> > It's just that this magic bit makes After= line in lots of units I've > >> > seen (and wrote) redundant, so can it be dropped and skipped in any > >> > new units or it's better to be explicit in this case? > >> > > >> > >> Do you have that many target units? > > > > Ah, I missed the "target units" part, but even then > > "Requires=network.target + After=network.target" is a common > > enough pattern for services that need network to be up at startup and > > After= line is present in each one of them: > > > > Dependencies are added to target for units that it pulls. Not other way round. > Hm, indeed, I should've read that statement much more carefully. > > /lib/systemd/system/noip.service:Requires=network.target > > /lib/systemd/system/dnscache.service:Requires=network.target > > /lib/systemd/system/tinydns.service:Requires=network.target > > /lib/systemd/system/remote-fs.target:Requires=network.target > > /lib/systemd/system/ziproxy.service:Requires=network.target > > /lib/systemd/system/ejabberd.service:Requires=network.target > > /lib/systemd/system/dhcpd.service:Requires=network.target > > I tentatively think that these should be either After or Requisite. Do > you really want to start network every time one of those services gets > started (assuming there were reasons to have network stopped at this > moment)? Since they can't function without network (usually failing if interface doesn't exists), pulling in network as a dependency seem to be sensible thing to do, no point to start dependencies manually. Disabling the network in such configuration can be done by masking network.target, either via symlink to /dev/null or systemd.blacklist_units= parameter. After+Requisite seem to be an alternative, although enabling service and it's dependencies explicitly for it not to fail looks counter-intuitive to me - services usually pull in needed deps without requiring you to enable whole pyramid of them below, constantly failing on any missing piece. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 13:06, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Thu, 17 Mar 2011 01:04:35 +0100 > Lennart Poettering wrote: > > > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > > > 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. > > > > Well, actually there is. > > > > If DefaultDependencies= is "yes" (which it is by default) for target > > units then they'll automatically gain an After= for all untis they have > > Wants= or Requires= on. > > > > (We currently do not document what DefaultDependencies= actually means > > for the specific unit types. We probably should...) > > > > Can this behavior be relied upon or this might change in future > releases? Yes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 14:32, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > Ah, I missed the "target units" part, but even then > > "Requires=network.target + After=network.target" is a common > > enough pattern for services that need network to be up at startup and > > After= line is present in each one of them: > > > > Dependencies are added to target for units that it pulls. Not other way round. > > > /lib/systemd/system/noip.service:Requires=network.target > > /lib/systemd/system/dnscache.service:Requires=network.target > > /lib/systemd/system/tinydns.service:Requires=network.target > > /lib/systemd/system/remote-fs.target:Requires=network.target > > /lib/systemd/system/ziproxy.service:Requires=network.target > > /lib/systemd/system/ejabberd.service:Requires=network.target > > /lib/systemd/system/dhcpd.service:Requires=network.target > > I tentatively think that these should be either After or Requisite. Do > you really want to start network every time one of those services gets > started (assuming there were reasons to have network stopped at this > moment)? Yes, I agree fully with Andrey. For two reasons: A) I think it is important to implement lose coupling, i.e. ejabber works fine without network, hence a Requires= is not really necessary. and B) Whether a service is enabled or not should be a decision of the admin he can control with "systemctl enable" and "systemctl". When you use Wants/Requires too often you bit by bit take this away from the admin, since simply enabling ejabber might also enable the network in your case, which is not necessarily what the admin wants. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 12:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > (We currently do not document what DefaultDependencies= actually means > > for the specific unit types. We probably should...) > > > > Yes, please. > > BTW I remember there were other magic directories besides xxx.wanted, > should not they be documented as well? Are they also handled by > "systemctl enable/disable"? There's only .wants and .requires, nothing else. I have now added a bit of text about .requires to the man pages. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 23:28, Lennart Poettering (lenn...@poettering.net) wrote: > > > (We currently do not document what DefaultDependencies= actually means > > > for the specific unit types. We probably should...) > > > > > > > Can this behavior be relied upon or this might change in future > > releases? > > Yes. With that I wanted to say that yes, you may rely on this behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Sat, 12.03.11 13:00, Andrey Borzenkov (arvidj...@mail.ru) wrote: > 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. So, Kay and I discussed this yesterday, and we came to the conclusion that Andrey's proposal is the right thing to do. It should be the specific implementations which pull in the generic targets and *not* the other way round. This might be surprising at first, but Andrey, Kay and I think this makes most sense. Here's an attempt of a longer explanation for this: First of all most of these special targets should eventually go away without replacement. They exist primarily to provide compatibility with SysV/LSB where generic facility names were a crucial requirement for ordering things properly. However, in a world with socket and bus activation this is not necessary anymore. If all services are socket and bus activatable, then all clients can just use them without the need to wait for anything explicitly. Currently existing targets of this kind are at least: nss-lookup.target, http-daemon.target, dbus.target, mail-transfer-agent.target, rpcbind.target, rtc-set.target, syslog.target. Of these dbus.target can probably be retired right now, since we only support bus activated dbus daemons. And syslog.target probably soon too, since all relevant syslog implementations have been patched by now. And rpcbind very likely too soon. Then there is network.target. This is a bit more complex case. $network in LSB headers is mostly use to synchronize services to the point where "the network is up". I generally believe that the idea that such a point in tim exists is just broken. Networks aren't static beasts anymore. They come and go. Machines move. Machines are reconfigured all the time. An application which is written in a way that it expects the network to be up from the moment it is started to the moment it exits is just broken. That's 90's style hacking, but in 2011 network software should acknowledge that things have changed and subscribe to netlink so that they follow network changes and can be started at any time. Thankfully a lot of software does that correctly now. However, we have to acknowledge that a lot of software still doesn't, for example stuff like ntpdate. For that reason we probably need to keep network.target for a while, even if it's mostly an indication of software sucking and not so much an indication of excellence on sw design. So, now let's have a close look at network.target, NetworkManager.service and network.service (i.e. the classic Fedora network init scripts. The ordering between these units is pretty clear: network.target should be AFTER the other two, and that's about it. But what about the requirement deps? The obvious choice would be to make network.target require (or want) the two services. But that would mean that any start transaction that includes network.target would also include the two services. And is this really what we want? No, clearly not I would say. network.target is supposed to be used to order the various network setup systems against the various network consuming services, but it shouldn't mean that just to enforce this ordering having apache.service in your transaction also causes you to have *all* the configured network setup implementations in it as well. i.e. if at boot NM and the old network scripts got started, and then the user stopped NM (but didn't disable it), then starting apache should definitely *not* start NM again. And hence there should *not* be a wants/requires dep from network.target on NM.service nor network.service. But what about the other direction? We definitely want network.target in the boot transaction if NM or network.service is part of it too. Because only then the network consuming services can be synchronized properly. Hence we want those two services pull in network.target, as a signal "Hey, we implement this, and when it is up, you can use it". So, here's what I am going to do now: a) Modify the Description= strings of the various target units where this applies to make clear that they exist for SysV/LSB compat only. b) Remove dbus.target c) Add a Wants+Before to syslog.socket on syslog.target. Since the socket is already e
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 23:28, Lennart Poettering (lenn...@poettering.net) wrote: > On Thu, 17.03.11 13:06, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > On Thu, 17 Mar 2011 01:04:35 +0100 > > Lennart Poettering wrote: > > > > > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > > > > > 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. > > > > > > Well, actually there is. > > > > > > If DefaultDependencies= is "yes" (which it is by default) for target > > > units then they'll automatically gain an After= for all untis they have > > > Wants= or Requires= on. > > > > > > (We currently do not document what DefaultDependencies= actually means > > > for the specific unit types. We probably should...) > > > > > > > Can this behavior be relied upon or this might change in future > > releases? > > Yes. Hah, turns out this is actually already documented, in systemd.target(5) where it should be. So yupp, it's so reliable, that this is already documented since a while ;-) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, 18 Mar 2011 00:34:19 +0100 Lennart Poettering wrote: > > But what about the other direction? We definitely want network.target in > the boot transaction if NM or network.service is part of it too. Because > only then the network consuming services can be synchronized > properly. Hence we want those two services pull in network.target, as a > signal "Hey, we implement this, and when it is up, you can use it". > > So, here's what I am going to do now: > > a) Modify the Description= strings of the various target units where >this applies to make clear that they exist for SysV/LSB compat only. > > b) Remove dbus.target > > c) Add a Wants+Before to syslog.socket on syslog.target. Since the >socket is already enough to make logging possible this is all that is >needed. > > d) fix the systemd code which parses LSB headers to interpret Provides >like this. > > e) patch NM upstream and NTP in F15 to add the necessary dependencies. > > And Andrey, thanks a lot for pointing us to this problem and the > solution! > > Questions? Anything we didn't think about? > That'd make all the systems with currently enabled services in network.target.wants misconfigured - network should fail on these unless something Requires= (or Wants=) network.target explicitly (which was marked as a wrong way to depend on network), so I think maybe some larger announcement for packagers is in order as well, to leave less broken systems and angry users as a result ;) -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev wrote: > On Fri, 18 Mar 2011 00:34:19 +0100 > Lennart Poettering wrote: > >> >> But what about the other direction? We definitely want network.target in >> the boot transaction if NM or network.service is part of it too. Because >> only then the network consuming services can be synchronized >> properly. Hence we want those two services pull in network.target, as a >> signal "Hey, we implement this, and when it is up, you can use it". >> >> So, here's what I am going to do now: >> >> a) Modify the Description= strings of the various target units where >> this applies to make clear that they exist for SysV/LSB compat only. >> >> b) Remove dbus.target >> >> c) Add a Wants+Before to syslog.socket on syslog.target. Since the >> socket is already enough to make logging possible this is all that is >> needed. >> >> d) fix the systemd code which parses LSB headers to interpret Provides >> like this. >> >> e) patch NM upstream and NTP in F15 to add the necessary dependencies. >> >> And Andrey, thanks a lot for pointing us to this problem and the >> solution! >> >> Questions? Anything we didn't think about? >> > > That'd make all the systems with currently enabled services in > network.target.wants misconfigured - network should fail on these > unless something Requires= (or Wants=) network.target explicitly (which > was marked as a wrong way to depend on network), so I think maybe some > larger announcement for packagers is in order as well, to leave less > broken systems and angry users as a result ;) > I am not sure I really understand this. When you speak about services WantedBy network.target - do you mean services activated on-demand when network becomes available. Could you give example? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, 18 Mar 2011 14:11:47 +0300 Andrey Borzenkov wrote: > On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev wrote: > > > > That'd make all the systems with currently enabled services in > > network.target.wants misconfigured - network should fail on these > > unless something Requires= (or Wants=) network.target explicitly (which > > was marked as a wrong way to depend on network), so I think maybe some > > larger announcement for packagers is in order as well, to leave less > > broken systems and angry users as a result ;) > > > > I am not sure I really understand this. When you speak about services > WantedBy network.target - do you mean services activated on-demand > when network becomes available. No, these are services that make the network work. They are pulled in for network.target, so any service starting after that will be able to bind to some interface or connect to a remote host. > Could you give example? Sure, I have this mix (for two machines): rpcbind.service rpcidmapd.service rpcstatd.service wicd.service ypbind-mt.service epmd.service ipsec.service net@core.service net-firewall.service net@he6.service net-lo.service net@tnet.service net@xtit.service net@.service is just a template to start static network configuration script, other net-* stuff follows the same purpose, the rest are more or less what comes with the distro. I'm fairly sure that common units for other stuff like connman, wpa_supplicant or dhcpcd will also be in this category. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, Mar 18, 2011 at 3:06 PM, Mike Kazantsev wrote: > On Fri, 18 Mar 2011 14:11:47 +0300 > Andrey Borzenkov wrote: > >> On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev wrote: >> > >> > That'd make all the systems with currently enabled services in >> > network.target.wants misconfigured - network should fail on these >> > unless something Requires= (or Wants=) network.target explicitly (which >> > was marked as a wrong way to depend on network), so I think maybe some >> > larger announcement for packagers is in order as well, to leave less >> > broken systems and angry users as a result ;) >> > >> >> I am not sure I really understand this. When you speak about services >> WantedBy network.target - do you mean services activated on-demand >> when network becomes available. > > No, these are services that make the network work. > They are pulled in for network.target, so any service starting after > that will be able to bind to some interface or connect to a remote host. > > OK, but how they are broken now? If you start network.target by some external means (IIRC it was not started by default) it will continue to work as before - nothing is changed. I really miss something obvious here. >> Could you give example? > > Sure, I have this mix (for two machines): > > rpcbind.service > rpcidmapd.service > rpcstatd.service > wicd.service > ypbind-mt.service > epmd.service > ipsec.service > net@core.service > net-firewall.service > net@he6.service > net-lo.service > net@tnet.service > net@xtit.service > > net@.service is just a template to start static network configuration > script, other net-* stuff follows the same purpose, the rest are more or > less what comes with the distro. > I'm fairly sure that common units for other stuff like connman, > wpa_supplicant or dhcpcd will also be in this category. > > > -- > Mike Kazantsev // fraggod.net > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Wed, 23 Mar 2011 15:35:35 +0300 Andrey Borzenkov wrote: > On Fri, Mar 18, 2011 at 3:06 PM, Mike Kazantsev wrote: > > On Fri, 18 Mar 2011 14:11:47 +0300 > > Andrey Borzenkov wrote: > > > >> On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev > >> wrote: > >> > > >> > That'd make all the systems with currently enabled services in > >> > network.target.wants misconfigured - network should fail on these > >> > unless something Requires= (or Wants=) network.target explicitly (which > >> > was marked as a wrong way to depend on network), so I think maybe some > >> > larger announcement for packagers is in order as well, to leave less > >> > broken systems and angry users as a result ;) > >> > > >> > >> I am not sure I really understand this. When you speak about services > >> WantedBy network.target - do you mean services activated on-demand > >> when network becomes available. > > > > No, these are services that make the network work. > > They are pulled in for network.target, so any service starting after > > that will be able to bind to some interface or connect to a remote host. > > > > > > OK, but how they are broken now? If you start network.target by some > external means (IIRC it was not started by default) it will continue > to work as before - nothing is changed. > > I really miss something obvious here. > You want ipsec started and postgresql and remote-fs started after it's up along with the network. Note the difference. Before: started: network.target.wants/wicd.service started: network.target.wants/ipsec.service started: network.target started: remote-fs.target (Requires=network.target) started: multi-user.target.wants/postgresql.service (only After=network.service) After: NOT started (fail!): network.target.wants/wicd.service NOT started (fail!): network.target.wants/ipsec.service NOT started (fail!): network.target started w/o net/ipsec (fail!): remote-fs.target (no Requires=network.target now!) started w/o net/ipsec (fail!): multi-user.target.wants/postgresql.service So, if you won't update ipsec.service to pull in network.target and push it to multi-user.target (by disable/enable or rm/ln) you have a broken setup wrt network. Note that the last step modifies /etc and shouldn't be easy to do automagically in packages, so maybe a warning will be better there. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Wed, Mar 23, 2011 at 7:44 PM, Mike Kazantsev wrote: > On Wed, 23 Mar 2011 15:35:35 +0300 > Andrey Borzenkov wrote: > >> On Fri, Mar 18, 2011 at 3:06 PM, Mike Kazantsev wrote: >> > On Fri, 18 Mar 2011 14:11:47 +0300 >> > Andrey Borzenkov wrote: >> > >> >> On Fri, Mar 18, 2011 at 8:31 AM, Mike Kazantsev >> >> wrote: >> >> > >> >> > That'd make all the systems with currently enabled services in >> >> > network.target.wants misconfigured - network should fail on these >> >> > unless something Requires= (or Wants=) network.target explicitly (which >> >> > was marked as a wrong way to depend on network), so I think maybe some >> >> > larger announcement for packagers is in order as well, to leave less >> >> > broken systems and angry users as a result ;) >> >> > >> >> >> >> I am not sure I really understand this. When you speak about services >> >> WantedBy network.target - do you mean services activated on-demand >> >> when network becomes available. >> > >> > No, these are services that make the network work. >> > They are pulled in for network.target, so any service starting after >> > that will be able to bind to some interface or connect to a remote host. >> > >> > >> >> OK, but how they are broken now? If you start network.target by some >> external means (IIRC it was not started by default) it will continue >> to work as before - nothing is changed. >> >> I really miss something obvious here. >> > > You want ipsec started and postgresql and remote-fs started after it's > up along with the network. > > Note the difference. > > Before: > started: network.target.wants/wicd.service > started: network.target.wants/ipsec.service > started: network.target What pulled in network.target? > started: remote-fs.target (Requires=network.target) > started: multi-user.target.wants/postgresql.service (only > After=network.service) > > After: > NOT started (fail!): network.target.wants/wicd.service > NOT started (fail!): network.target.wants/ipsec.service > NOT started (fail!): network.target > started w/o net/ipsec (fail!): remote-fs.target (no Requires=network.target > now!) > started w/o net/ipsec (fail!): multi-user.target.wants/postgresql.service > > So, if you won't update ipsec.service to pull in network.target and > push it to multi-user.target (by disable/enable or rm/ln) you have a > broken setup wrt network. > Note that the last step modifies /etc and shouldn't be easy to do > automagically in packages, so maybe a warning will be better there. > > > -- > Mike Kazantsev // fraggod.net > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Wed, 23 Mar 2011 19:57:23 +0300 Andrey Borzenkov wrote: > On Wed, Mar 23, 2011 at 7:44 PM, Mike Kazantsev wrote: > > On Wed, 23 Mar 2011 15:35:35 +0300 > > Andrey Borzenkov wrote: > > > >> > >> OK, but how they are broken now? If you start network.target by some > >> external means (IIRC it was not started by default) it will continue > >> to work as before - nothing is changed. > >> > >> I really miss something obvious here. > >> Guess it's just me being confused, proposed changes shouldn't really break stuff by themselves indeed. > > > > You want ipsec started and postgresql and remote-fs started after it's > > up along with the network. > > > > Note the difference. > > > > Before: > > started: network.target.wants/wicd.service > > started: network.target.wants/ipsec.service > > started: network.target > > What pulled in network.target? > > > started: remote-fs.target (Requires=network.target) ^ > > started: multi-user.target.wants/postgresql.service (only > > After=network.service) network.target here, of course. > > > > After: > > NOT started (fail!): network.target.wants/wicd.service > > NOT started (fail!): network.target.wants/ipsec.service > > NOT started (fail!): network.target > > started w/o net/ipsec (fail!): remote-fs.target (no > > Requires=network.target now!) Guess that won't change, even though new mechainism seem to imply that only stuff reside in .wants here should pull in network.target now, but that Requires= line isn't part of the proposed changes. > > started w/o net/ipsec (fail!): multi-user.target.wants/postgresql.service > > > > So, if you won't update ipsec.service to pull in network.target and > > push it to multi-user.target (by disable/enable or rm/ln) you have a > > broken setup wrt network. > > Note that the last step modifies /etc and shouldn't be easy to do > > automagically in packages, so maybe a warning will be better there. On a separate note: remote-fs.target doesn't have any WantedBy= or RequiredBy= lines in "systemctl show" (even w/o and network mounts in fstab) and Requires=network.target, so network.target seem to be always activated, but that's probably unrelated issue. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
