[systemd-devel] Systemd startup question

[Lennart Poettering]

On Mi, 10.01.18 20:38, Boyce, Kevin P [US] (AS) (Kevin.Boyce at ngc.com) wrote:

> Good Afternoon list,
> 
> I am having a problem with my systemd service file and I think I now understand the problem. I'll describe below, but I'm hoping there is a way around it which someone may be able to illuminate me on.
> 
> I am developing an rpm package with software which gets installed under /opt/my/bin/service.  Imagine I have a corresponding directory in /opt/my/etc/systemd/system/my-service.service incorporated into the package.  As part of the package installation the post install script runs systemctl enable /opt/my/etc/systemd/system/my-service.service
> 
> My service file has an After=basic.target, Before=network.target,  WantedBy=Default.target, and  ExecStart=/opt/my/bin/service.
> 
> All of the symlinks appear to be ok.  After installation when the user runs systemctl start my-service.service everything works as expected.
> 
> However, when rebooting everything is not so nice.  In the journal one can observe the error "Cannot add dependency job for unit my-service.service, ignoring: Unit not found."
> 
> /opt happens to be on a separate partition than / and /usr.  I'm assuming during systemd startup that systemd is parsing  everything before /opt is moutned and coming across a broken symlink /etc/systemd/system/my-service.service.
> 
> Is there any other solution than removing the symlink and installing my-service.service unit file in /etc/systemd/system directly?
> We have a requirement to keep our software neatly confined in /opt/my.

We generally require that unit files reside in the search path at
early boot-up. The logic in systemd is designed so that the boot
transaction is calculated early on, and that means we need access to
all units that are supposed to start. Now, /opt is frequently split
out, and hence unit files can't really be located there... Sorry.

You can copy the unit file however in your case, no?

Lennart

-- 
Lennart Poettering, Red Hat