[systemd-devel] daemon-reload does not pick up changes to /etc/systemd/system during boot

[Alex Aminoff]

On 10/13/22 07:59, Lennart Poettering wrote:
> On Mi, 12.10.22 16:54, Alex Aminoff (aminoff at 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