[systemd-devel] Should automount units for network filesystems be Before=local-fs.target?
Hello all, At present, when systemd-fstab-generator creates an automount unit for an fstab entry, it applies the dependencies that would have been put into the mount unit into the automount unit instead. For a local filesystem, this automount unit would be Before=local-fs.target. For a network filesystem, it gets Before=remote-fs.target. If the mount is not noauto, it also gets a corresponding WantedBy= or RequiredBy= dependency. Would it make more sense for the automount unit to be ordered before (and, if not noauto, be pulled in by) local-fs.target, even for network filesystems? In a sense, the automount is a local filesystem, even though the thing that will eventually be mounted over the top of it isn't. Furthermore, this change would allow services that use automounted network filesystem to simply block until the filesystem has been mounted. Currently, for this to work correctly during boot, services need to be given explicit dependencies (e.g. After=remote-fs.target or RequiresMountsFor=...), since otherwise they may get started before the automount unit has started and thus be able to "see" the underlying filesystem. I'm trying to work out what might break with such a change. I suppose it is possible somebody has two automounted network filesystems nested within one another... the second automount would be dependent upon the first being mounted, but that mount won't happen until the network is brought up, which is after local-fs.target. This doesn't seem like a particularly likely configuration though. Is there any other reason this change wouldn't work? -- Michael Chapman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fully volatile running from ram
On Tue, 25.04.17 13:13, jr (darwinsker...@gmail.com) wrote: > hello, > > in a fully-volatile boot scenario /usr from a physical disk gets mounted on > top of an instance of a tmpfs. my first question is why is that necessary? > (the tmpfs part i mean) I am not sure I grok what you are trying to say? tmpfs is how on Linux you can easily have a volatile file system, as it lives entirely in memory and never hits the disk (admittedly modulo swapping). > my second question is, would it be possible to do the same but rather than > mounting the /usr *populate* the said tmpfs with OS tree from said physical > disk, preferably in a blocked or fs cached setup (db-cache or bcachefs). i > realise that this can be done easily in initrd or even initramfs can hold > the /usr but the problem there is when we boot "developmen" and not > "production" in which case we want updates to be written to disk. I am not grokking this question either, but keeping the whole OS in memory of course means you need a lot of memory. Moreover depending on disk speeds it means your boot will be quite slow, as you copy stuff over every single time before you can boot. If you copy things around like that during boot the best thing would be to do it in the initrd, as otherwise you are running the system already, that you are about to prepare for running, and dropping open references the the old files is hard (though not entirely impossible, after all there is "systemctl daemon-reexec" and things). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running a set of group isolated from other services?
Benno Fünfstück schrieb am Mi., 26. Apr. 2017 um 13:05 Uhr: > Hi, > > I have the problem that I want to run a set of services that are isolated > from the other services. In particular, I'd like to: > > * share some environment variables between these services, that aren't > available for services outside the group > * be able to stop all the services in the group and wait for proper > shutdown > * (would be nice) load services for the group from a different directory > than the default one > * (would be nice) be able to add transient services to the group with > systemd-run > > Is such a thing possible with systemd? If not, is it feasible to implement > something like this (even if it doesn't match exactly what I want)? > > Regards, > Benno > Just to add if that wasn't clear: I'd like to run this group for multiple different sets of environment variables, and be able to "start" the group for some assignment of environment variables (these variables will not change during the lifetime of the group though) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running a set of group isolated from other services?
Hi, I have the problem that I want to run a set of services that are isolated from the other services. In particular, I'd like to: * share some environment variables between these services, that aren't available for services outside the group * be able to stop all the services in the group and wait for proper shutdown * (would be nice) load services for the group from a different directory than the default one * (would be nice) be able to add transient services to the group with systemd-run Is such a thing possible with systemd? If not, is it feasible to implement something like this (even if it doesn't match exactly what I want)? Regards, Benno ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
