Discussion:
question about Wants and unit start-up order
(too old to reply)
Brian J. Murrell
2018-03-23 15:41:44 UTC
Permalink
Raw Message
If I have:

Wants=system.slice nss-lookup.target named-setup-rndc.service

in named-pkcs11.service, so shouldn't mean that named-pkcs11.service
will be started up before the nss-lookup.target is Reached/Started?

That doesn't seem to be the case on my system:

Mar 23 09:44:03 server.interlinx.bc.ca systemd[1]: Reached target User and Group Name Lookups.
Mar 23 09:44:03 server.interlinx.bc.ca systemd[1]: Starting User and Group Name Lookups.
Mar 23 09:47:35 server.interlinx.bc.ca systemd[1]: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...
Mar 23 09:47:42 server.interlinx.bc.ca systemd[1]: Started Berkeley Internet Name Domain (DNS) with native PKCS#11.

Am I misunderstanding what systemd is trying to tell me above? Is it
not saying that the nss-lookup.target was reached (and therefore
services that depend on it can go ahead) before the DNS service was
actually even started?

If I am misunderstanding, is there a better way to understand the order
that units were started in than looking at the journal?

Cheers,
b.
Mantas Mikulėnas
2018-03-23 19:45:52 UTC
Permalink
Raw Message
Post by Brian J. Murrell
Wants=system.slice nss-lookup.target named-setup-rndc.service
in named-pkcs11.service, so shouldn't mean that named-pkcs11.service
will be started up before the nss-lookup.target is Reached/Started?
No, dependencies do not imply any specific ordering. (The only exception is
when a .target wants/requires another unit.)

In other words, you will need to additionally list the same units in
After=, or in certain cases in Before=. (For example, named is a nss-lookup
provider, so it should have "Before=nss-lookup.target", but
"After=named-setup-mdc.service".)

On another note, Wants=system.slice is *very* redundant – all system
services go into that slice anyway.
--
Mantas Mikulėnas
Brian J. Murrell
2018-03-23 19:52:18 UTC
Permalink
Raw Message
Post by Mantas Mikulėnas
No, dependencies do not imply any specific ordering. (The only
exception is
when a .target wants/requires another unit.)
That seems odd but I will leave that aside for a moment...
Post by Mantas Mikulėnas
In other words, you will need to additionally list the same units in
After=, or in certain cases in Before=. (For example, named is a nss-
lookup
provider, so it should have "Before=nss-lookup.target", but
"After=named-setup-mdc.service".)
That is the case:

# systemctl show named-pkcs11.service | grep -ie ^before -e ^after
Before=nss-lookup.target shutdown.target
After=system.slice named-setup-rndc.service tmp.mount -.mount var.mount network.target systemd-journald.socket basic.target named-dhcp.service

So it's still puzzling why they report out of order in the journal.
Post by Mantas Mikulėnas
On another note, Wants=system.slice is *very* redundant – all system
services go into that slice anyway.
That was output from systemctl show so it was probbaby just reflecting
that, as the one above does.

Cheers,
b.
Mantas Mikulėnas
2018-03-24 15:39:15 UTC
Permalink
Raw Message
Post by Brian J. Murrell
Post by Mantas Mikulėnas
No, dependencies do not imply any specific ordering. (The only exception is
when a .target wants/requires another unit.)
That seems odd but I will leave that aside for a moment...
Post by Mantas Mikulėnas
In other words, you will need to additionally list the same units in
After=, or in certain cases in Before=. (For example, named is a nss-
lookup
provider, so it should have "Before=nss-lookup.target", but
"After=named-setup-mdc.service".)
# systemctl show named-pkcs11.service | grep -ie ^before -e ^after
Before=nss-lookup.target shutdown.target
After=system.slice named-setup-rndc.service tmp.mount -.mount var.mount
network.target systemd-journald.socket basic.target named-dhcp.service
So it's still puzzling why they report out of order in the journal.
Post by Mantas Mikulėnas
On another note, Wants=system.slice is *very* redundant – all system
services go into that slice anyway.
That was output from systemctl show so it was probbaby just reflecting
that, as the one above does.
Which systemd version do you run? In v232,

nss-lookup.target:Description=Host and Network Name Lookups
nss-user-lookup.target:Description=User and Group Name Lookups
--
Mantas Mikulėnas
Brian J. Murrell
2018-03-24 15:54:04 UTC
Permalink
Raw Message
Post by Mantas Mikulėnas
Which systemd version do you run? In v232,
systemd-219-42.el7_4.10.x86_64
Post by Mantas Mikulėnas
nss-lookup.target:Description=Host and Network Name Lookups
nss-user-lookup.target:Description=User and Group Name Lookups
Same here:

# systemctl show nss-lookup.target | grep Description
Description=Host and Network Name Lookups
# systemctl show nss-user-lookup.target | grep Description
Description=User and Group Name Lookups

For my purposes, it is "Host and Network Name Lookups" that I am
looking to gate other things on but that target needs to wait for named
to be up before it is considered reached, which does not seem to be
happening here.

Cheers,
b.
Mantas Mikulėnas
2018-03-24 15:57:17 UTC
Permalink
Raw Message
Post by Brian J. Murrell
Post by Mantas Mikulėnas
Which systemd version do you run? In v232,
systemd-219-42.el7_4.10.x86_64
Post by Mantas Mikulėnas
nss-lookup.target:Description=Host and Network Name Lookups
nss-user-lookup.target:Description=User and Group Name Lookups
# systemctl show nss-lookup.target | grep Description
Description=Host and Network Name Lookups
# systemctl show nss-user-lookup.target | grep Description
Description=User and Group Name Lookups
For my purposes, it is "Host and Network Name Lookups" that I am
looking to gate other things on but that target needs to wait for named
to be up before it is considered reached, which does not seem to be
happening here.
But your log snippet is talking about nss-user-lookup.target.
--
Mantas Mikulėnas
Loading...