On Tue, Feb 16, 2016 at 9:20 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > Initial shutdown is via two targets (as opposed to specific services),
Since not everybody in this thread may be familiar with systemd, I'll just add a quick definition. When systemd says "target" - think "virtual service." The equivalent in openrc would be an init.d script that has dependencies but which doesn't actually launch any processes. Targets also take the place of runlevels in systemd. Just as with runlevels in openrc they are used to synchronize milestones during bootup, but the design is much more generic. Presumably openrc hard-codes runlevels like sysinit, boot, and default. In systemd I believe it just looks at the config file and directly launches the desired target, and then the dependency chain for that pulls in all the targets that precede it. Targets can depend on other targets, and services can depend on previous targets. The other dimension is that unit files describe what target they are typically associated with if it isn't the default. So, you don't run into the sorts of situations you have with openrc that if you want to enable mdraid support you need to remember to add it to the boot runlevel. That might be a relatively-easy thing to add support for in openrc actually. Hopefully that makes Dunan's summary easier to read for anybody who doesn't speak systemdese. Another bit of background that might be helpful is that systemd also manages mounts directly. It parses fstab and creates a network of mount units with appropriate dependencies. Whether you unmount /var/tmp using "umount /var/tmp" or "systemctl stop var-tmp.mount" systemd updates the status of the var-tmp.mount unit to a stopped status. I believe if you add a noauto line to fstab it will create a mount unit automatically and not start it, and if you made it mount on boot I think it would actually be mounted as soon as you save the file in your editor (systemd can monitor config files for changes - all of this is governed by scripts/software called generators). So, systemd in general tries to stay aware of the state of mounts. I suspect that isn't just firing off a script to find/unmount anything that is mounted. From Dunan's email it sounds like you could create a mount unit and explicitly not set a conflict with the unmount target which would cause the filesystem to remain mounted at shutdown. I have no idea what that would do to unmounting the root. -- Rich
