Bug 754127 - RFE: Support checking of status via SysV initscript's status action
RFE: Support checking of status via SysV initscript's status action
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
Depends On:
Blocks: systemd-RFE 752863
  Show dependency treegraph
Reported: 2011-11-15 08:44 EST by Lukas Zapletal
Modified: 2012-02-29 10:24 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-29 10:24:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lukas Zapletal 2011-11-15 08:44:22 EST
We are using thin Ruby web server which spawns 1..N worker processes. We wrote a simple sysv init script for that:


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 (                                       ...
		  └ 2336 thin server (

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.
Comment 1 Michal Schmidt 2011-11-15 10:40:08 EST
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.
Comment 2 Kay Sievers 2011-11-15 11:36:37 EST
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

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.
Comment 3 Jóhann B. Guðmundsson 2012-02-27 06:44:41 EST
From my pov this should be closed as WONTFIX...

Note You need to log in before you can comment on or make changes to this bug.