Should I migrate the scripts to systemd format?
Yes.
You're being bitten by a well-known flaw in System 5 rc
scripts. It's not really anything to do with systemd. You could have hit the flaw if you'd managed to start the scripts up in parallel some other way, such as with startpar
for example.
It's well known that grepping the output of ps
is prone to races, both against grep
and against ongoing system state, and one can find decades of people reporting hitting these same faults over and over again with different shell scripts. It's daft and wrongheaded, and mentioned in the "BUGS" section of the BSD manual page for ps
. The world should know better by now.
The world does know better, and has for some time. We've had service managers that work properly, without all of these bodged-together mechanisms involving grepping the process list and files that may or may not contain the right number, since the early 1990s. You should definitely, if you are being hit by this and other race conditions, throw those rickety, failure-prone, idiosyncratic, and messy System 5 rc
scripts away and use proper service management. No ifs; no buts; no "quick workarounds" bodges upon the bodges that you are already using (the extra grep
s being themselves a bodge in the first place).
There are many such service managers available. You don't have to use systemd. The various scripts that one would write for runit, nosh, or perp are as simple as the unit files that one would write for systemd.
In the nosh and systemd way of doing things, you don't have the two primary services checking for and running the secondary one. That's the job of the service management system. Rather you simply declare a dependency from the two primary services upon the secondary one, so that the service management system knows that when it is told to start Agentdaemon.service
and Securitydaemon.service
it has to start common.service
as well. In systemd service units this would be a Requires=
or a Wants=
setting.
Further reading
The service
command is a "compatibility" tool to help people migrate from sysvinit to systemd. It's a smart program that tries to work out your current init
system and will call sysvinit, upstart or systemd calls as necessary.
Your question is a little "tell the future" in nature; today Debian allows different init systems to work and the service
command will try and work it all out. But Debian 9? Who knows what that will support... We could end up with superinit
to replace systemd
, and the service
command will be updated...
The problem is that this solution may not be cross-platform consistent; will service
work with CentOS or SuSE? Will systemctl
?
If I was writing my own stuff then I'd just stick with systemctl
for all systemd
based platforms, but have a massive test for all OS variants I support.
Best Answer
Systemd and init have
pid = 1
Check for systemd