Re: Reloading configuration after mount unit

[Norbert Lange <nolange79@xxxxxxxxx>]

Am Fr., 18. Juni 2021 um 21:05 Uhr schrieb Silvio Knizek <killermoehre@xxxxxxx>:
>
> 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
> <killermoehre@xxxxxxx>:
> > >
> > > 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel