Centos – Common location for systemd unit files on Ubuntu and RHEL

centosrhelsystemdUbuntu

I would like to create a scripted install for a list of Systemd services. This installation should support both Ubuntu (starting with version 16.04) and RHEL/CentOS (starting with version 7.2)

I read RHEL docs and found three paths that I could store unit files in, these paths are:

/usr/lib/systemd/system/
/lib/systemd/system/
/etc/systemd/system

What is the correct location for services that fulfills these criteria:

Unit files are there for non-system level services (application specific services)
No already existing OS level services are overwritten
The location is identical on Ubuntu and RHEL/CentOS

Best Answer

In default Red Hat distributions, /lib is a symlink to /usr/lib, but it appears those are different locations in Ubuntu.

According to the systemd documentation, /usr/lib/systemd/system/ is designated to hold upstream unit files that would not be edited by users and instead be provided and updated via packages.

The /etc/systemd/system is designated as where user provided unit files would be. Packages should not override or update anything in /etc/systemd/system. You can also use /etc/systemd/system to override existing unit files.

So using /etc/systemd/system should be the most compatible between different distributions.

Related Solutions

Linux – Enabling ‘linked’ unit files in Systemd

The man page is misleading.

~~systemctl link /root/myservice.service~~

systemctl enable /root/myservice.service

The first makes it possible for you to do systemctl start myservice. The second makes it possible for myservice to be started automatically (which, as @Julien pointed out, automatically adds the link).

I think... I've been trying to wrap my head around this all day.

Systemd linked unit files on mounted disk fail to load

As explained by @StephenHarris the problem is at the moment systemd tries to read the unit, the file that's symlinked isn't available yet

To just have systemd reload the units after it has mounted :

[Unit]
Description=reloads units stored in /mnt/data
DefaultDependencies=no
After=mnt-data.mount
Requires=mnt-data.mount

[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload

[Install]
WantedBy=local-fs.target

This will cause the units to become available, because this time this time the target of the symlinks is mounted.

But by that time, the list of jobs needing to be run to reach the default.target is already built, and the service won't be started.

To have it also restart your service:

[Unit]
Description=restart unit stored in /mnt/data
Requires=mnt-data.mount

[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload
ExecStartPost=/bin/systemctl start sprinterd.service

[Install]
WantedBy=multi-user.target

Alternatives:

I've tested with ExecStart= & ExecStartPost=, but it should obviously work with ExecStartPre= & ExecStart=
if it's all about 1 single unit, you might as well : ExecStart=/bin/systemctl enable /mnt/data/sprinterd.service instead of daemon-reload
if there are multiple services, do the daemon-reload, then start a single unit that uses ConsistsOf= or PartOf= to load all the multiple services.
If its NFS (or other networked system), of course local-fs.target isn't your best Installation option, obviously.

For a more old-school SysVinit-style approach, put the systemctl commands inside /etc/rc.local and chmod +x that file.

And then go smuggly post on Devuan's mailing list how you needed SysVInit to fix b0rked SystemD ;-)

Best Answer

Related Solutions

Linux – Enabling ‘linked’ unit files in Systemd

Systemd linked unit files on mounted disk fail to load

Related Question