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>