User configs, BTRFS subvolume for /home and automatic service start during boot?

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Do, 03.05.18 21:07, Thorsten Schöning (tschoening at am-soft.de) wrote:

> Hi all,
> 
> I'm using Ubuntu 16.04 LTS server with BTRFS, which created one
> subvolume for / and another one for /home. While I do like this setup,
> it makes me trouble with how I deploy our own software developed for
> various customers. For many reasons that software is stored under
> /home[/tenant1|tenant2|...] currently, including systemd service files
> nowadays. The good thing is that enabling those files is as easy as
> 
> > systemctl enable ...
> 
> with the absolute path. The bad thing is that because /home is another
> file system, during boot systemd can't find my service files and
> therefore can't start my services[1].

Hmm, you said /home was a subvolume? That suggests they are on the
same fs? Not following here?

> I'm looking for alternatives[2] now and thought of user configs. The
> good thing is that my service files seem to be properly available to
> systemd if I login e.g. using SSH, the status of the service is loaded
> and I'm able to start it manually. But I have trouble getting systemd
> to automatically start the service during boot and even during SSH
> login.
> 
> I'm pretty sure to already have use the suggested "loginctl enable-linger ...",
> but might have some error somewhere of course. But it might as well be
> that the subvolume /home itself is making trouble here again. In the
> end, there's the following sentence in the docs which doesn't
> distinguish between system wide and user configs:
> 
> > 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).
> 
> So, are user configs for systemd supported to be placed on a non-root
> file system AND be started during boot time? I don't have any users
> logging in in the end.

The comment above only applies to the systemd system instance,
i.e. PID 1. It does not apply to systemd user instances. I figure we
should clarify that in the docs...

Lennart

-- 
Lennart Poettering, Red Hat