Systemd drop-in fails to create PID file

Christian Grabowski asked:

I have a drop-in for systemd-machined at the path /etc/systemd/system/systemd-machined.service.d/10-machined-pid-file.conf. when I run systemctl status systemd-machined I do see the lines

Drop-In: /etc/systemd/system/systemd-machined.service.d

However, I do not see a PID file in /var/run/. Which based on my drop-in:


I believe there should not be any issue creating that PID file. Is there something I am missing?

My answer:

The PIDFile= setting does not create a PID file. That is still up to the service itself to do, the same as it has been for the last 40 years. Rather, this option tells systemd where to find an existing PID file (if any). In most cases it’s not required at all, as systemd will keep services in their own cgroups and does not need a PID file to keep track of them. However, systemd will delete a PID file when the service exits, if the service fails to clean up after itself.

From the documentation:

Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here, although it will remove the file after the service has shut down if it still exists.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.