On 18.06.2021 20:48, Norbert Lange wrote: > Am Fr., 18. Juni 2021 um 16:35 Uhr schrieb Silvio Knizek > <killermoe...@gmx.net>: >> >> 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
