We are using thin Ruby web server which spawns 1..N worker processes. We wrote a simple sysv init script for that: https://gist.github.com/1367019 Now the problem, let's configure the service to spawn at least two processes. Then start the service and issue status command: systemctl status katello.service katello.service - SYSV: Init script for katello Loaded: loaded (/etc/rc.d/init.d/katello) Active: active (running) since Tue, 15 Nov 2011 12:09:08 +0100; 3min 26s ago Process: 2297 ExecStop=/etc/rc.d/init.d/katello stop (code=exited, status=0/SUCCESS) Process: 2317 ExecStart=/etc/rc.d/init.d/katello start (code=exited, status=0/SUCCESS) Main PID: 1648 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/katello.service ├ 2328 thin server (0.0.0.0:5000) ... └ 2336 thin server (0.0.0.0:5001) Now let's kill one sub-process: kill 2336 Status still reports this service as started/activee/loaded. I, as a developer, would like to set systemd to either explicitly check for the status through the sys v init script "status" call or to be able to tell systemd how to treat multiple pids. The system status can be considered as started only if all the processes (N) are running. I did not find any information in the documentation how to do that, maybe it's just a lack of documentation.
This is not currently supported. systemd never asks the service about its status. It assumes the status can always be inferred from the existence of processes in the cgroup and the liveness of the process with the main PID. In a discussion with Kay we concluded that we might add support for "ExecStatus=..." for this purpose. Not primarily for the benefit of native units, but for improved compatibility with SysV. For SysV initscripts ExecStatus would be "/etc/rc.d/init.d/$service status". We dismissed the idea of supporting multiple pidfiles (PIDFilesDir=...) because it would be messy and less generic. There are some expected difficulties. Currently systemd assumes it always knows the status of all services. For services using ExecStatus= this will not be possible. We need to check what breaks. And systemd definitely won't be able to act as a supervisor for these services.
We need to carefully decide how far we need to go with sysv compat here. Calling out to init scripts to query the status provides on one hand greater compatibility, but is also a big step backwards to require that. And more impotantly, we will be unable to supervise services, which is one of the main goals of systemd. How would we enable ExecStatus=? We surely do not want do that for all sysv scripts. Fedora does not allow init scripts in packages anymore, and requires native service files. There is a FESCO feature that might block all such packages from the distro. I personally would be fine if we do not support that at all and require the very few (rather strange) cases to convert to the foo@.service instantiated model. We required the same for the pretty complex NFS script case. So I tend to require converting of the script logic instead of enhancing systemd with something that is against the basic design.
From my pov this should be closed as WONTFIX...