Re: [systemd-devel] Reloading configuration after mount unit

2021-06-19 Thread Andrei Borzenkov
On 19.06.2021 11:00, Norbert Lange wrote:
>>
>> What you could try is creating a new unit in /etc/systemd/system/
>> --- systemd-reload.service ---
>> [Unit]
>> Description=Reload systemd
>> Requires=usr-local.mount
>> After=usr-local.mount
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/bin/systemctl --no-block daemon-reload
>>
>> [Install]
>> WantedBy=usr-local.mount
>> ---
>> and than a »systemctl daemon-reload && systemctl enable systemd-
>> reload.service«.
>> In theory (because completly untested) this unit should be activated as
>> soon as your /usr/local mount point is ready.
> 
> Yeah, I did something similar. systemd seems to get the new targets,
> including adding the sysinit.wants symlinks to sysinit.target.
> But doesn't start them.
> 

As already explained systemd builds "transaction" (set of units that are
dependencies of default.target) once on boot and does not reevaluate it.
To start newly available units you need to actually request to start
them. I.e. you would need something like

systemctl --no-block start usr-local.target

where usr-local.target pulls in those units in /usr/local.
usr-local.target can itself be on /usr/local. As you need to configure
your units in /usr/local as dependencies anyway, you can just as well
add them as dependency to usr-local.target instead of sysinit.target.
You can actually have both in case /usr/local will be available early.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Reloading configuration after mount unit

2021-06-19 Thread Norbert Lange
Thanks for the explanations.

Norbert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Reloading configuration after mount unit

2021-06-19 Thread Norbert Lange
Am Fr., 18. Juni 2021 um 21:05 Uhr schrieb Silvio Knizek :
>
> Am Freitag, dem 18.06.2021 um 19:48 +0200 schrieb Norbert Lange:
> > Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek
> :
> > >
> > > Hi Norbert,
> > >
> > > make sure your /usr/local mount is done in the initrd and that you
> use
> > > »systemctl link /path/to/unit.service« to enable them.
> > That's not really helping, I don't want to chug in tons of tools in
> > the initramfs this is no desktop system.
> > systemctl link shouldnt be necessary, as
> /usr/local/lib/systemd/system
> > is a standard unit path.
>
> You're right with the path, I re-checked it.
> For your initrd the general suggestion is to actually include systemd
> in it. See https://systemd.io/INITRD_INTERFACE/ for everything.
> >
> > Since there is a systemd-update-done that changes /etc I would have
> thought that
> > systemd rereads the configuration (as /etc/systemd/system could have
> > changed) during startup.
> > I would want that for /usr/local/lib/systemd/system after this path
> > was made available through a mount.
> >
> > If systemd assumes the whole /usr drive to be static and has no way
> to
> > dynamically reload and "retarget"
> > (adding new wants/requires dependencies to starting/started targets)
> > then I guess that's the end of it.
> >
> > I dont know if thats the case or if I just dont know how (as
> > systemd-update-done allows a changing /etc I would assume systemd
> > would rescan it for units/dependencies)
>
> systemds internal unit representation is actually static. Unit files
> are only read when started as PID1 after the generators ran, while
> switch-root'ing from the initrd and everytime you run »systemctl
> daemon-re{load,exec}« (there are transient units as well, but this
> would be to much for here).
>
> What you could try is creating a new unit in /etc/systemd/system/
> --- systemd-reload.service ---
> [Unit]
> Description=Reload systemd
> Requires=usr-local.mount
> After=usr-local.mount
>
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/systemctl --no-block daemon-reload
>
> [Install]
> WantedBy=usr-local.mount
> ---
> and than a »systemctl daemon-reload && systemctl enable systemd-
> reload.service«.
> In theory (because completly untested) this unit should be activated as
> soon as your /usr/local mount point is ready.

Yeah, I did something similar. systemd seems to get the new targets,
including adding the sysinit.wants symlinks to sysinit.target.
But doesn't start them.

> >
> > >
> > > For the automount behaviour, you need to add
> > > »noauto,x-systemd.autmount,x-systemd.idle-timeout=10s«
> > > to the options part in the /etc/fstab. See man:systemd.mount for
> more
> > > information.
> >
> > Thats Automount, but I want "LazyUnmount",
> > and the suggestion kinda contradicts "make sure your /usr/local mount
> > is done in the initrd"
>
> The »x-systemd.idle-timeout=10s« actually unmounts the disk as soon as
> 10s long the disk is idle. Idle is defined as
> - open file descriptors and
> - process working directory.
> So LazyUnmount (which you can define in an actual .mount unit) wouldn't
> change anything IMHO.

The disk wont be idle when *deciding* to unmount (services run from
it, and likely the shell where you type umount).
Norbert
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel