SystemD SysV generator and mounts

systemd

So systemd-sysv-generator converts old style init.d files into systemd service files. But it might do this before all mounts have been mounted.

I have some legacy commercial software that lives in /opt which is a separate mount point. It creates a symlink from /etc/init.d/their_service to a file in /opt

So when the server boots, systemd-sysv-generator cant yet read the linked file and fails to create a service and thus fails to start the service.

As the legacy software is managed by another team and they have the power to update it themselves, I don't want to start copying the file out of /opt and replacing the symlink. Or worse, try rewriting this into a systemd service myself.

Is there any way to have systemd-sysv-generator fire after opt.mount?

Best Answer

One option might be to create a drop-in for their service, that specifies dependencies/order.

For example:

$ sudo mkdir /etc/systemd/system/their_service.service.d
$ sudo vi /etc/systemd/system/their_service.service.d/50-require_mounts.conf
[Unit]
Wants=network.target remote-fs.target
After=network.target remote-fs.target

However, the SysV script could be adapted to sort this problem (https://www.freedesktop.org/software/systemd/man/systemd.special.html):

remote-fs.target Similar to local-fs.target, but for remote mount points.

systemd automatically adds dependencies of type After= for this target unit to all SysV init script service units with an LSB header referring to the "$remote_fs" facility.

Related Solutions

Systemd – How to Set Environment Variable in Service

Times change and so do best practices.

The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.

In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, override.conf), and in this file you can add to or override any part of the unit shipped by the distribution.

For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf:

[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"

Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.

For reference, the old way was:

The recommended way to do this is to create a file /etc/sysconfig/myservice which contains your variables, and then load them with EnvironmentFile.

For complete details, see Fedora's documentation on how to write a systemd script.

How to disable serial console after successful boot (systemd/grub2)

This feels awfully hacky, but it does the job. It will stop the serial terminal after the machine has been booted.

/etc/systemd/system/killconsole.service:

[Unit]
Description=kill console after boot
After=default.target

[Service]
Type=simple
ExecStart=/bin/systemctl stop serial-getty@ttyS2.service

[Install]
WantedBy=default.target

Then simply run systemctl enable /etc/systemd/system/killconsole.service to enable the unit.

You could also trigger the above using a separate timer unit that wouldn't fire until X minutes after boot. If you give that a try, be sure to rip out the Install section from the service and run a systemctl disable on it to remove it from default.target's wants list.

Note that the definition of 'successful boot' may vary. For example, if the box's network is hosed, all of the services may start up fine but you might still need serial access. As such, I'd highly recommend creating a small script to ensure that the system is alive and well (and on the network) and placing it in an ExecStartPre option. If the Pre script returns a failed exit code, then the service won't be run and the serial console won't be disabled.

Best Answer

Related Solutions

Systemd – How to Set Environment Variable in Service

How to disable serial console after successful boot (systemd/grub2)

Related Topic