[systemd-devel] When is a unit "loaded"?
Daniel Wang
wonderfly at google.com
Thu Jul 12 16:10:06 UTC 2018
Excellent. Thanks for the detailed answers.
On Wed, Jul 11, 2018 at 11:17 PM Zbigniew Jędrzejewski-Szmek <
zbyszek at in.waw.pl> wrote:
> On Wed, Jul 11, 2018 at 06:52:12PM -0700, Filipe Brandenburger wrote:
> > Hey Daniel!
> >
> > On Wed, Jul 11, 2018 at 5:16 PM Daniel Wang <wonderfly at google.com>
> wrote:
> > > I have a unit, say foo.service, on my system that's in
> /usr/lib/systemd/system, but disabled by preset.
> >
> > Not that it matters, but presets don't really matter here. The unit is
> > disabled, period.
> >
> > > On system boot, it doesn't show as "loaded" per `systemctl --all |
> grep foo`.
> >
> > Because there's no reference to it in units systemd sees, so systemd
> > doesn't need to load it.
> >
> > At bootup, systemd will simply start with default.target and then
> > recursively load the units it needs.
> >
> > See this link for more details:
> >
> https://www.freedesktop.org/software/systemd/man/bootup.html#System%20Manager%20Bootup
> >
> > `systemctl --all` will only show the units in memory, so foo.service
> > won't be listed since it's not loaded.
> >
> > > So if I override it with a file with the same name but under
> /etc/systemd/system, `systemctl cat foo.service` will show the one under
> /etc without the need for a `systemctl daemon-reload`.
> >
> > Yes, because it's not loaded.
> >
> > > If I create another service unit, bar.service, which has a After=
> dependency on foo.service, and start bar, foo.service will show as loaded.
> And then if I try to override it, `systemctl cat foo.service` will print a
> warning saying a daemon-reload is needed.
> >
> > Yes. If systemd sees a reference for that unit (even if it's an
> > After=), it will need to load it, since it needs to record the
> > dependency between the units in the internal memory structures, so it
> > needs a reference to the unit, and it loads it to have a complete
> > reference to it...
> >
> > > Nothings seems incorrect, but I have a few questions:
> > > - Which units are loaded on-boot and which are not?
> >
> > Only default.target and recursively any unit referred to by the loaded
> units.
>
> What you are saying is all correct, with two very minor nipticks:
> - the "default" unit can be overridden with systemd.unit= and 1/2/3, so
> it's not always default.target,
> - also, there are other units that'll be loaded, for example anything
> pulled in by SYSTEMD_WANTS= in udev rules (if the hardware is present),
> and .device/.mount/.swap units can also pull other stuff in, and such
> units may be created based on the state of the system. So it's
> not just the tree starting at the "default" unit, but also a bunch
> of other subtree.
>
> > > - Is the After= dependency alone enough to have systemd load a unit?
> Are there any other dependency directives that will result in the same
> effect?
> >
> > Yes, I believe any reference to units will trigger the unit to be
> > loaded. As I mentioned, systemd wants to keep the state in memory, so
> > loading the unit will allow it to keep complete state.
> >
> > An exception (haven't checked it, but I expect it) is references in
> > the [Install] section (such as Also=) since those are only used by
> > `systemctl enable` and are not really loaded into memory as far as I
> > can tell (but I might be wrong here, and these might trigger the unit
> > to load as well.)
> Yes, anything in [Install] doesn't matter (except that after the
> installation is done, the symlinks that are created do matter).
>
> Zbyszek
>
--
Best,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180712/bc46128e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180712/bc46128e/attachment-0001.bin>
More information about the systemd-devel
mailing list