Linux – SysV init scripts to systemd migration in RHEL7

linuxrhelsystemdsysvinit

Please find the Sys V Init scripts for (User processes)Agent and Security daemon in Linux.

  1. Agent Daemon startup script
    /etc/rc.d/init.d/Agentdaemon
    /etc/rc.d/rc5.d/S91Agentdaemon

  2. Security Daemon startup script
    /etc/rc.d/init.d/Securitydaemon
    /etc/rc.d/rc5.d/S91Securitydaemon

Let us assume both agent and securiy daemons need a common parent say common agent. If common agent is not started at the time of reboot, any of the other daemons will start common agent and the other daemon will
skip to start the common agent. There is 'ps' command check to see if common agent is running or not to skip creation in both the Agentdaemon and Securitydaemon scripts.
This has worked fine in RHEL 6.2. But in RHEL 7, I am seeing two common agents are running.

And also I doubt that systemd has started both agent and security daemon parallely. Somehow 'ps' has not shown the common agent running.

Ex: ps -ef | grep common | grep -v grep | awk '{print $2}' is not showing the common process started by other script and hence the other script also starts the common agent.

Is there any way I can avoid the startup scripts run in parrallel or Should I migrate the scripts to systemd format?
Quick workaround is more interested than migrating all the scripts from Sys V init type to systemd.

Best Answer

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 greps 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

Related Question