Re: [systemd-devel] Reloading configuration after mount unit
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
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
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
Re: [systemd-devel] Reloading configuration after mount unit
On 18.06.2021 20:48, Norbert Lange wrote: > Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek > : >> >> Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: >>> Hello, >>> >>> I have an extra mount for /usr/local (Tools + Services which are just >>> useful for development), classically done vie /etc/fstab. >>> >>> Now there are a few systemd services within /usr/local/lib and systemd >>> does not seem to load/reload those and start the ones that add a >>> sysinit.wants. >>> >>> currently I have to do the following to get a "full start": >>> systemctl daemon-reload >>> systemctl start default.target >>> >>> What would be the correct way to cause systemd to reevaluate configuration? >>> I get that this generally could lead to bad behaviour (endless >>> reconfiguration if cycles), >>> but for something hierarchical like mount-paths it should be possible. >>> >>> I could think of a unit having an after/requires to usr-local.mount or >>> using a path unit watching PathChanged=/usr/local/lib/systemd. >>> At any rate, I am not sure how I could tell systemd to start new units >>> wanted by eg. >>> sysinit.target if this was already fully started. `systemctl start >>> default.target` seems >>> a bit dangerous. >>> >>> Another, less important issue is that I cant set lazy unmount in fstab. >>> >>> Norbert. >> 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. > > 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. The only thing systemd-update-done does is touch /etc/.updated touch /var/.updated It has nothing to do with "rereading configuration". > I would want that for /usr/local/lib/systemd/system after this path > was made available through a mount. > systemd will always scan unit path when you attempt to reference unit not yet loaded. So this "just works". But you apparently need something different. You want systemd to retrospectively scan new directory for any unit definition that is mentioned in any already loaded unit and re-evaluate dependencies. systemd was never designed for it. It was designed to statically build full closure of units to be started on boot, and do it just once. I suppose it is theoretically possible to do it in lazy way - start with just immediate dependencies of default.target and add dependency of each unit when you are about to start it. That would do what you want as long path becomes available before systemd starts units that reference these path. But that would need radical redesign of the whole dependency chain. > 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. > It does not assume anything about /usr, it just builds full set if units to be started on boot once. Anything not available (visible) at this moment will not be included in boot "transaction". > 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) > >> >> 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" > > Norbert > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ 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
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.
>
> >
> > 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.
(sorry for sending twice. Forgot the ML)
___
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
On Fri, 2021-06-18 at 19:48 +0200, Norbert Lange wrote: > 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. Systemd does not necessarily assume the whole of /usr to be mounted at once - you could have binaries and data in submounts and systemd could wait for those - but there is no "normal" way to add units in the middle of operation. There is "daemon-reload", but it's more meant for things like online updates, not part of a standard boot sequence. Normally the complete set of units to start in a boot should be known early, not appended to in parts as things are mounted. So you could have tools in a separately-mounted /usr/local, but I think you'd need to have the systemd configuration for them in the main /usr to have things behave nicely. ___ 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
Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek : > > Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: > > Hello, > > > > I have an extra mount for /usr/local (Tools + Services which are just > > useful for development), classically done vie /etc/fstab. > > > > Now there are a few systemd services within /usr/local/lib and systemd > > does not seem to load/reload those and start the ones that add a > > sysinit.wants. > > > > currently I have to do the following to get a "full start": > > systemctl daemon-reload > > systemctl start default.target > > > > What would be the correct way to cause systemd to reevaluate configuration? > > I get that this generally could lead to bad behaviour (endless > > reconfiguration if cycles), > > but for something hierarchical like mount-paths it should be possible. > > > > I could think of a unit having an after/requires to usr-local.mount or > > using a path unit watching PathChanged=/usr/local/lib/systemd. > > At any rate, I am not sure how I could tell systemd to start new units > > wanted by eg. > > sysinit.target if this was already fully started. `systemctl start > > default.target` seems > > a bit dangerous. > > > > Another, less important issue is that I cant set lazy unmount in fstab. > > > > Norbert. > 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. 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) > > 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" 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
Am Freitag, dem 18.06.2021 um 15:04 +0200 schrieb Norbert Lange: > Hello, > > I have an extra mount for /usr/local (Tools + Services which are just > useful for development), classically done vie /etc/fstab. > > Now there are a few systemd services within /usr/local/lib and systemd > does not seem to load/reload those and start the ones that add a > sysinit.wants. > > currently I have to do the following to get a "full start": > systemctl daemon-reload > systemctl start default.target > > What would be the correct way to cause systemd to reevaluate configuration? > I get that this generally could lead to bad behaviour (endless > reconfiguration if cycles), > but for something hierarchical like mount-paths it should be possible. > > I could think of a unit having an after/requires to usr-local.mount or > using a path unit watching PathChanged=/usr/local/lib/systemd. > At any rate, I am not sure how I could tell systemd to start new units > wanted by eg. > sysinit.target if this was already fully started. `systemctl start > default.target` seems > a bit dangerous. > > Another, less important issue is that I cant set lazy unmount in fstab. > > Norbert. 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. 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. HTH Silvio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reloading configuration after mount unit
Hello, I have an extra mount for /usr/local (Tools + Services which are just useful for development), classically done vie /etc/fstab. Now there are a few systemd services within /usr/local/lib and systemd does not seem to load/reload those and start the ones that add a sysinit.wants. currently I have to do the following to get a "full start": systemctl daemon-reload systemctl start default.target What would be the correct way to cause systemd to reevaluate configuration? I get that this generally could lead to bad behaviour (endless reconfiguration if cycles), but for something hierarchical like mount-paths it should be possible. I could think of a unit having an after/requires to usr-local.mount or using a path unit watching PathChanged=/usr/local/lib/systemd. At any rate, I am not sure how I could tell systemd to start new units wanted by eg. sysinit.target if this was already fully started. `systemctl start default.target` seems a bit dangerous. Another, less important issue is that I cant set lazy unmount in fstab. Norbert. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
