1

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.

Srikanth Ganesan
  • 181
  • The quick workaround is stop running the agent and security daemon from systemd by disabling their unit files and use the old approach to start the daemons. – Thushi Jun 02 '15 at 11:42
  • You need to re-read the question, Thushi. The questioner is using the old approach to starting the the daemons; it isn't working (because of one of the many well-known problems with rc scripts); and the questioner has asked about using systemd unit files instead. – JdeBP Jun 02 '15 at 15:48
  • We do not want the customer to go and kill process on each machine(where the agents will be deployed on lot of machines). Anyhow Thank you Thushi and JdeBP – Srikanth Ganesan Jun 05 '15 at 07:03

1 Answers1

2

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

JdeBP
  • 68,745