Yrurtj

Don't normally post here but I am ripping my hair out over this one.
I have a Python script that forks when it launches, and is responsible for starting a bunch of other processes.
This script used to be launched at startup via sysvinit, but recently I upgraded to Debian Jessie so have adapted it to launch via systemd.

Unfortunately, I'm running into an issue I can't work out. When you launch the script directly in a user shell, it launches it's child processes correctly, and when the script exits the child processes are orphaned and continue to run.

When launched Via systemd, if the parent process exits, the children all exit too (Well, the Screen's that they launch in die and appear as Dead???)

Ideally I need to be able to restart the parent script without killing all the child processes, is there something that I am missing?

Thanks!

[Unit]

Description=Server commander

After=network.target



[Service]

User=serveruser

Type=forking

PIDFile=/var/Server/Server.pid



ExecStart=/var/Server/Server.py

ExecStop=/bin/kill -s TERM $MAINPID



[Install]

WantedBy=multi-user.target

Edit:
It's probably relevant for me to point out that the Python script is essentially a 'controller' for its child processes. It starts and stops servers in gnu screens as requested from a central server. It is normally always running, it doesn't spawn services and exit. There are cases however where I would like to be able to reload the script without killing child processes, even if that means the processes are orphaned off to pid 1. In fact, it wouldn't even matter if the Python script started off processes as a parent process, if that is even possible.

A better explanation of how it works:

• Systemd spawns /Server.py


• Server.py forks and writes the pid file for Systemd


• Server.py then spawns server processes in gnu screen based on its instructions


• Server.py continues to run to perform any restarts requested from the server

When launching without Systemd, Server.py can be restarted and the gnu screens it launches are unaffected. When launching with Systemd, when Server.py shuts down, instead of those screen processes being orphaned off to pid 1, they are killed.

I managed to fix this simply by setting KillMode to process instead of control-group (default). Thanks all

I have a Python script that forks when it launches, and is responsible for starting a bunch of other processes.

Which indicates that you are doing it wrongly. More in this in a moment.

when the script exits the child processes are orphaned and continue to run.

This is not correct dæmon behaviour. If the "main" process — in this case the child that you have forked, since you have specified Type=forking — exits, systemd considers the service to have deactivated and terminates any other still-running processes (in the control group) in order to tidy up.

Sometimes the conversion from System 5 rc scripts to systemd is not straightforward, because the right way to do things under systemd is quite different. The right way to do (say) OpenVPN, or OpenStack, or OSSEC HIDS in systemd is not the same as one would do it with an rc script. The fact that you have a script that is forking, then spawning a whole load of grandchildren processes, then exiting expecting those grandchildren to keep running indicates that you are perpetrating the same sort of horror as ossec-control, albeit with two less levels of forking. If you find yourself writing a "master" script that checks "enable" flags and runs child processes for the "enabled" parts of your system, then you are making the same mistake as the horrendous ossec-control.

No such home-grown mechanisms are necessary with systemd. It already is a service manager. Per https://unix.stackexchange.com/a/200365/5132, the right way to go about this in systemd is not to have one service that spawns some wacky and confused attempt to have "sub-services". It is to have each child process as a fully fledged systemd service in its own right. Then one enables and disables, and starts and stops, the various parts of the system using the normal systemd controls. As you can see in the OSSEC HIDS case, a simple template service unit covers almost all (one exception is at https://askubuntu.com/a/624871/43344) services, allowing one to do things such as systemctl enable ossec@agentlessd.service to enable an optional agentlessd service, without any need at all for the horrendous "master script" mechanism that was needed with System 5 rc.

There are plenty of cases, not perhaps as extreme as OSSEC HIDS, where such rethinking is necessary. MTSes like exim and sendmail are two such. One might have had a single rc script that spawns a queue runner, an SMTP Submission dæmon, and an SMTP Relay dæmon, with a bunch of ad hoc shell variables in a configuration file to control exactly which are run. But the right way to do this with systemd is to have three proper service units (two of which have associated socket units) and no ad hoc stuff at all, just the regular mechanisms of the service manager.

In the parent process, you could just wait on the children instead of dying.