Open kirichkov opened 7 years ago
Can you hold off merging this? I want to also add the option for the script to drop down privileges if it's run as root.
Nevermind. It makes little sense to implement this. One has to just fix where the location of the PID file should be.
Thanks again for your PR @kirichkov.
I don't think I'll merge this in its actual form. Adding this feature increases the size of the code to handle something that most init system I know can do. I'm sure you can handle a non-forking binary with initv, upstart and systemd.
Patch to add command line option parsing is interesting though, would you be able to separate it from the rest?
To be honest I have not experimented with systemd but can it actually write down a PID file? I did not find such an option, hence - fork, write PID file.
Most init system can manage process staying in the foreground, not requiring any pid file.
For which type of system would you need this feature?
I use this for monit - it's a lot more reliable when you have a pid file than using it's process matching feature. And I use monit to make sure no process hangs - e.g. hass once in a while hangs and starts using 100% but on a single core, which is not noticable unless you run top, because it's not total 100% usage, but the process is still hung, and I've set monit to restart it if monit consumes more than 20% continuously for 10 minutes.
Monit also helps me abstract managing processes and I can just ignore whether it's a systemV, upstart or systemd underneath.
I don't mind removing the forking while keeping the pid file creation. Or I can reverse, i.e. fork, if a command line switch is present and by default run it non-forking.
This makes the script into a proper daemon, that by default forks and runs in the background.
I've also added handling for command line options. A peculiarity is that if you run the systemd script and you want to see the debug log you should change the ExecStart line to include the
-v
(verbose) option