[systemd-devel] Systemd loads units before btrfs subvolumes are mounted

[Lennart Poettering]

On Tue, 24.05.16 22:21, Rashmi Ranjan Mohanty (RashmiRanjan.Mohanty at microfocus.com) wrote:

> Hi,
> 
> Our whole software is installed into /opt. So the systemd unit files
> are also there in /opt and the units are enabled to start on boot
> using the command "systemctl enable <Absolute Path of unit
> file>". But if the /opt is a subvolume on a btrfs file system, when
> the system boots, sometimes (or on some systems) systemd tries to
> load the units even before /opt subvolume is mounted. As a result it
> does not find the unit file and fails to load the unit. Once
> everything is mounted, if we try to start the units manually,
> everything works fine. Here is the snippet of the error....

This is simply not supported. Services to be started at boot must be
accessible when systemd transitions from the initrd into the host
system. Thus, if you place them in /opt, and make /opt an independent
mount, then systemd won't cover this. Unit files are really like
/etc/fstab itself, they cannot be split out into a different FS
mounted later. (this is because we want to determine the initial
transaction only once, at very early boot, and we can do so only if we
actually know everything to start)

(a hackish way around this could be to issue "systemctl daemon-reload"
half-way during the boot process when the new mount point showed up,
but that's really just a gross hack and comes with other problems)

What I don't understand in your case though is why you use an explicit
mount for /opt anyway... The nice thing about btrfs is that subvolumes
behave pretty much like normal directories that just have a bit more
features. And because of that there's no need to mount them
explicitly. Just create a subvolume normally and everything should be
good, it will then be available at the right place the instant the
parent subvolume is mounted too.

Lennart

-- 
Lennart Poettering, Red Hat