Le mardi 20 décembre 2011 à 16:05 +0100, Christian Boltz a écrit :
Hello,
Am Dienstag, 20. Dezember 2011 schrieb Frederic Crozat:
Le lundi 19 décembre 2011 à 21:20 +0100, Christian Boltz a écrit :
Am Samstag, 17. Dezember 2011 schrieb Cristian Rodríguez:
On 18/12/11 13:53, Christian Boltz wrote:
To name another example: check the current (quite verbose) output of "rcapparmor status". How can this (running the "aa-status" command) be done with systemd when someone checks the status? I know about ExecStart, ExecReload and ExecStop, but I don't see something like ExecStatus in systemd.service(5).
You probably know that there is nothing like a permanently running AppArmor process, so looking up the status somewhere in the process table ("is the started process still running?") is impossible. I allso don't like the idea to rely on "we loaded the profiles, so they must still be there" because someone could have unloaded them manually.
Back to my question - how can this be handled in a *.service file?
It can't. systemctl status foo.service is supposed to return an errorcode (and some systemd text output), in a standard form and that's it.
That's a clear answer. Not my favorite one, but thanks nevertheless.
rc* SUSE-ish shouldn't rely on initscript "status" command to output anything but the "standard" form.
OK, but I still have a problem - how can systemd detect the status of AppArmor?
There's no running process systemd could detect.
Such services (like apparmor, SUSEfirewall, cpufreq) are considered as systemd as "RemainAfterExit" (cf man systemd.service) : they will look as "active" (ie running) service after the startup, not relying on a process to keep running
However, when not using .service where you can specify RemainAfterExit explicitly (ie when using initscript), we had to create a heuristic to try to guess if an initscript is a service which is starting a daemon or not (to detect properly if not having anything left running for this service is a failure or not). This heuristic is not perfect (unfortunately), so, we added two additional LSB like headers to be used for initscripts (it will be present in the pending maintenance update): # PIDFile: <path_for_pid_file> (this one is modeled after RH / Fedora initscript header) You specify the path of the PID file of the service and systemd will use it to detect if the service is active and running properly (instead of relying on heuristic to guess daemon PID and to detect when nothing else is running). Having this header implies RemainAfterExit will be set to "no" by systemd.
# X-Systemd-RemainAfterExit: Just like for a .service, it allows to tell systemd an initscript doesn't start any daemon and therefore, it shouldn't consider no daemon running is a failure.
The initscript calls "aa-status", prints its output and returns the status/errorcode based on $? of aa-status. How can I do this (execute a command when checking the status) with systemd to get at least the errorcode?
You can't, through systemd. The service will be based on either it is running (for a RemainAfterExit=false type) or it was run based on its error code (for a RemainAfterExit=true type).