08.01.2018 07:10, Marc Chamberlin пишет:
Hi - I am working on some service software for some ham radio services that I am porting from SysV to systemd management and I have a couple questions that I could use a bit of guidance on. (and yes I tried to Google for the answers, but no joy groking things in any deep fashion.)
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. A related question is how exactly does systemd use the PID file that is defined in a .service file?
Systemd expects that each service has one process that represents *the* service. When this process exits, from systemd point of view service has finished. How exactly this process is determined depends on service type, but this is technical detail. So your described architecture is the worst case for systemd. You can pull it off by declaring RemainAfterExit=true but it means no sensible service monitoring from systemd (as for it service has already been terminated). And if you consider it - your program starts a bunch of (independent) background processes. What should service manager now do when one of these processes dies? Can it ignore it? Should it restart it? Is the whole service still usable or must be declared failed (and possibly restarted)? It is better if you could re-arrange your software so that you start multiple systemd services where each service contains exactly one process for one hardware device. Then you can group them so you can start/stop/restart them collectively.
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? A related question is that the systemd status info that is shown, by default, shows the last few lines from the system log files. In my case that is kinda useless since I am starting up multiple child processes which are all contributing stuff, (in no particular order) to the system logs. Can this be turned off, or customized?
No, it is not possible as of now. Customization of status has been requested for quite some time but so far I am not aware of any actual work (nor of any chance for it to be included upstream).
My apologies if this is not the right forum to ask these questions, but I am working on OpenSuSE systems so thought this might be a good place to start and ask. Feel free to shoo me to some other group is this in not the appropriate place to ask such questions...
systemd mailing list? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org