Re: [systemd-devel] daemon-reload does not pick up changes to /etc/systemd/system during boot
On 10/13/22 07:59, Lennart Poettering wrote: On Mi, 12.10.22 16:54, Alex Aminoff (amin...@nber.org) wrote: As soon as the system is up I can ssh in and run systemctl start autofs and it works just fine. In journalctl -b I can see my rc.initdiskless running followed by the daemon-reload. But no autofs and no evidence that systemd tried to start autofs. My only guess is that somehow daemon-reload is not enough because as far as systemd is concerned we already queued up for starting all the services needed by multi-user.target back when we switched root from the initrd. daemon-reload just tells PID 1 to reload units, it has no direct effect on the job queue, it won't enqueue any deps that might have been added. You can issue "systemctl start --no-block multi-user.target" to reenqueue multi-user.target again which will then also reenqueue all its deps again, taking the new deps into consideration. An alternative is to use add in Upholds= type deps from multi-user.target to your service. That (somewhat recently added) dep type has a "continious" effect: whenever a unit is up that has a dep (or multiple of this kind it will have the effect that the listed dep will be started if not running. It means "systemctl stop" of a dependent service will be immediately undone though, i.e. it has quite different semantics from the usual Wants=. Thank you and Andrei for your helpful hints. I will research Upholds= but I am hopeful that systemctl start --no-block multi-user.target will work. Will test. Fortunately most of the stuff I am starting up based on the new /etc is pretty late in boot; if that were not the case I could likewise systemctl start some other target. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] daemon-reload does not pick up changes to /etc/systemd/system during boot
On Mi, 12.10.22 16:54, Alex Aminoff (amin...@nber.org) wrote: > As soon as the system is up I can ssh in and run systemctl start autofs and > it works just fine. In journalctl -b I can see my rc.initdiskless running > followed by the daemon-reload. But no autofs and no evidence that systemd > tried to start autofs. > > My only guess is that somehow daemon-reload is not enough because as far as > systemd is concerned we already queued up for starting all the services > needed by multi-user.target back when we switched root from the > initrd. daemon-reload just tells PID 1 to reload units, it has no direct effect on the job queue, it won't enqueue any deps that might have been added. You can issue "systemctl start --no-block multi-user.target" to reenqueue multi-user.target again which will then also reenqueue all its deps again, taking the new deps into consideration. An alternative is to use add in Upholds= type deps from multi-user.target to your service. That (somewhat recently added) dep type has a "continious" effect: whenever a unit is up that has a dep (or multiple of this kind it will have the effect that the listed dep will be started if not running. It means "systemctl stop" of a dependent service will be immediately undone though, i.e. it has quite different semantics from the usual Wants=. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] daemon-reload does not pick up changes to /etc/systemd/system during boot
On 12.10.2022 23:54, Alex Aminoff wrote: I am diskless booting Rocky Linux 9 , using an NFS mounted root. This works OK so far. However, I want to mount /etc/ as a tmpfs and load up a bunch of config files, then have systemd see the (new) /etc/systemd/system and use that in the rest of the boot process, bringing up some non-default services etc. I have a service that does the creation and copying of /etc which runs from local-fs-pre.target.wants: $ cat nber-rc-initdiskless.service [Unit] Description=Run NBER diskless setup including /sbin/copy_conf DefaultDependencies=no Before=local-fs-pre.target After=initrd-switch-root.service plymouth-switch-root.service OnFailure=emergency.target OnFailureJobMode=replace-irreversibly AssertPathExists=/etc/rc.initdiskless [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/bash /etc/rc.initdiskless ExecStart=systemctl daemon-reload StandardOutput=journal+console StandardError=journal+console [Install] WantedBy=local-fs-pre.target I then have for example /etc/systemd/system/multi-user.target.wants/autofs.service -> /usr/lib/systemd/system/autofs.service As soon as the system is up I can ssh in and run systemctl start autofs and it works just fine. In journalctl -b I can see my rc.initdiskless running followed by the daemon-reload. But no autofs and no evidence that systemd tried to start autofs. My only guess is that somehow daemon-reload is not enough because as far as systemd is concerned we already queued up for starting all the services needed by multi-user.target back when we switched root from the initrd. Correct. Hopefully it is something obvious that I am missing. No. See also thread https://lists.freedesktop.org/archives/systemd-devel/2022-September/048370.html
[systemd-devel] daemon-reload does not pick up changes to /etc/systemd/system during boot
I am diskless booting Rocky Linux 9 , using an NFS mounted root. This works OK so far. However, I want to mount /etc/ as a tmpfs and load up a bunch of config files, then have systemd see the (new) /etc/systemd/system and use that in the rest of the boot process, bringing up some non-default services etc. I have a service that does the creation and copying of /etc which runs from local-fs-pre.target.wants: $ cat nber-rc-initdiskless.service [Unit] Description=Run NBER diskless setup including /sbin/copy_conf DefaultDependencies=no Before=local-fs-pre.target After=initrd-switch-root.service plymouth-switch-root.service OnFailure=emergency.target OnFailureJobMode=replace-irreversibly AssertPathExists=/etc/rc.initdiskless [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/bash /etc/rc.initdiskless ExecStart=systemctl daemon-reload StandardOutput=journal+console StandardError=journal+console [Install] WantedBy=local-fs-pre.target I then have for example /etc/systemd/system/multi-user.target.wants/autofs.service -> /usr/lib/systemd/system/autofs.service As soon as the system is up I can ssh in and run systemctl start autofs and it works just fine. In journalctl -b I can see my rc.initdiskless running followed by the daemon-reload. But no autofs and no evidence that systemd tried to start autofs. My only guess is that somehow daemon-reload is not enough because as far as systemd is concerned we already queued up for starting all the services needed by multi-user.target back when we switched root from the initrd. Hopefully it is something obvious that I am missing. Thanks in advance for any help, - Alex Aminoff NBER
