On Tue, 24.05.16 22:21, Rashmi Ranjan Mohanty ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
