0

I've installed Ubuntu 16.04 LTS Server using BTRFS and got the following setup according /etc/fstab:

# <file system> <mount point>   <type>  <options>  <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=0841ef72-e9d4-45ca-af22-a403783859c6 /        btrfs   noatime,nodiratime,subvol=@ 0     1

# /home was on /dev/sda1 during installation
UUID=0841ef72-e9d4-45ca-af22-a403783859c6 /home    btrfs   noatime,nodiratime,subvol=@home 0 2

This pretty much makes sense to me, but resulted in trouble with my systemd-setup. Im storing software for different customers in /home and some of those provide daemons which should be started automatically during system boot by systemd. Something like the following:

/home/customer/someDaemon/cust_some_daemon.service

This can easily be deployed to systemd using systemctl enable ... with the absolute path above. I don't need to manually copy or link things, systemd handles everything, systemctl enable ... simply succeeds and links are created as expected.

What doesn't work is starting those services during boot time, systemd fails for all those services with a message that it can't find the linked files anymore. If I don't use /home but store those files in / directly or delete @home to not be an additional subvolume anymore, everything works as expected.

There's the following sentence in the docs for enable:

The file system where the linked unit files are located must be accessible when systemd is started (e.g. anything underneath /home or /var is not allowed, unless those directories are located on the root file system).

It's not clear to me what exactly the restriction is in this case: Is it the usage of an individual subvolume itself or is it because it needed to be mounted additionally? / needs to be mounted and is a subvolume in itself as well, but that is supported obviously. Especially because of the dynamic nature of BTRFS and ZFS regarding subvolumes, I would have expected that systemd at least supports multiple subvolumes within some common root filesystem or pool as well. But it either doesn't or can't deal with the additional mount point.

So what exactly is the problem here? Thanks!

2
  • 1
    Systemd can't run service, because at the moment volume with your /home part isn't mounted. BTRFS or any FS has nothing to do with it. The problem probably can be solved with correct usage of Requires= directive.
    – atype
    May 1, 2018 at 21:43
  • OK, so my misunderstanding was that I thought systemd handles mounting of / itself already as well, which it doesn't, but is left to initrd: unix.stackexchange.com/a/18055/174233 You should provide your comment as answer instead and explain more detailed what you mean with Requires. Who should require what exactly? As systemd doesn't find my service files, Requires in those shouldn't change much? May 2, 2018 at 7:16

3 Answers 3

1
  1. Create a service in root volume, which requires mounted home volume with RequiresMountsFor=, and then starts your services;
  2. Make the service user service, which will start at user login. More information on this.
2
  • I don't want to store my service files in / by purpose, makes deployment unnecessary difficult. User services depending on a login don't work, there are no users logging in. User services without login because of enable-linger didn't work in my tests yesterday as well.While the service status is OK when I login using SSH, the service is neither executed at boot time, nor during login, only using systemctl --user start ... manually. May 3, 2018 at 7:49
  • User services are a good idea and one can use those to work around the problem, at least if set up correctly regarding dependencies: lists.freedesktop.org/archives/systemd-devel/2018-May/… May 6, 2018 at 17:15
0

In your unit file specify that you have a dependancy on mount points other than the root file system and systemd will wait with starting your services until those have been mounted:

Consider for instance:

  • RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path.

Or add a dependancy on local-fs.target which is responsible for mounting all local file systems from /etc/fstab that have a label auto with for instance:

  • Requires=local-fs.target
  • After=local-fs.target
1
  • Neither of that seems to work, systemd is unable to find my files: Loaded: not-found (Reason: No such file or directory) systemctl disable ..., systemctl enable ..., systemctl start ... works, all links created, service runs. Not so after a reboot because of the former error message in systemctl status .... One can even see the links being available after /home is available again, but the service status is failed after reboot. May 2, 2018 at 9:32
0

The correct answer to my question is that /home is mounted by systemd after it that started working and therefore it can not resolve links to /home at the time systemd itself starts. The target of those links is only available later. OTOH / is mounted by initrd, systemd finds that already fully available and working when it starts. This has nothing to do with BTRFS or subvolumes itself, only what gets mounted when by whom.

Kudos to @atype for the explanation, but I don't like the other answers focusing on mostly wrong workarounds to the problem. I would like to have an answer really focusing on my question and explaining the underlying problem. If @atype would change his answer to include e.g. my explanation, I'll happily grant him the credits.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .