On 01/07/2018 10:36 PM, Per Jessen wrote:
Marc Chamberlin wrote:
My first question concerns forking and the PID file that systemd wants me to define. My main systemd exec script reads in a configuration file that a user defines which describes the types of hardware devices and services that need to be started. Basically this script will start up multiple daemons to handle the configuration the user wants to support, such as multiple hardware devices, multiple types of services to monitor traffic, log data, run beacons etc. I have the main systemd process fork itself, and from the child process it starts up a bunch of other processes, then the main process terminates itself and leaves all these child processes running indefinitely. So what should the PID files be set up for? The man pages state that for a forked process I should also have the child process define a PID file, but it is unclear what to do when there are multiple child processes started.
First thought - you need multiple service units, one per individual daemon. Your main process only duplicates what systemd does anyway.
Exactly my suggestion. Cookie cutter these systemd services and invoke them with "wants" and such. Make each as simple as possible. It costs nothing to have a handfull of systemd services running. Launch/enable/disable systemd services that you want with a bash shell if that saves time and brain cells but just the services you are interested in. Let those services make sure that necessary prerequisites are running via systemd wants etc. I hesitate to mention "do one thing, and do it well" in the same post as systemd but there you have it. (Running and ducking).
A related question is how exactly does systemd use the PID file that is defined in a .service file?
For sending signals to a process that has forked. (that process is expected to populate the pidfile).
All this goes away if you have one systemd service per process. Of course nothing prevents your main process from launching subordinate things but then you have a mixed bag that will be harder to manage.
My second question concerns the status reporting from a systemd daemon. I don't see a way this can be customized and configured to display special status info that should be displayed for all my child forked daemons. The old SysV scripts typically handled this via a case statement that handled Start, Stop, Restart, Status etc., but with the systemd configureation I only see hooks for Start and Stop, but not for Status. How do I get systemd to display and present a customized status report?
Well, all systemd knows about is whether a process is running or not. "systemctl status <service>". I guess anything else will have to come from the daemons individually.
With generic naming of your individual systemd services you can get globular systemctl status or show commands. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org