3

Is there a standard linux/unix pattern for communicating with long running process?

For example, I have few hundred process, written in c++, and running on various machines and I would like to send them a command like reload configuration, start, stop etc via shell scripts.

Anuj Balan
  • 7,629
  • 23
  • 58
  • 92
Jimm
  • 8,165
  • 16
  • 69
  • 118

3 Answers3

6

Signals.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • The OP wants to be able to communicate with remote processes too, most likely in a master-slave model. Signals won't help in that case isn't it? – Gangadhar Apr 05 '12 at 04:18
  • Thanks for that. I didn't know about it. Looks like this link explains that too - http://stackoverflow.com/questions/1512132/how-to-send-sigint-to-a-remote-process-over-ssh – Gangadhar Apr 05 '12 at 04:27
  • Signals has the drawback that from the time you learn the PID to the time you issue the `kill $PID` the system _could_ have reassigned that PID to a different process. Not likely, perhaps, but quite possible for a) you to learn your process' PID, b) your process to die, c) a new process to start and the d) OS to choose the PID you thought belonged to your process. making e) sending kill to that PID the wrong thing to do. – Jesse Chisholm Nov 12 '15 at 22:35
2

If you're trying to trigger simple actions like the start/stop/reload configuration as you've described, the most common method is to use signals.

From your shell script you can use the kill command to send a specific signal to a specific process. Within your process you would implement one or more signal handlers. The signal handler(s) are registered to receive one or more signals by using the signal() function, or the sigaction() function.

Conventionally SIGHUP is used to trigger a reload of configuration. SIGSTOP and SIGCONT may be appropriate for pausing and resuming.

man 7 signal will show you a complete list of available signals to choose from.

If you need to trigger more complex actions you can create a named pipe. Have your process create the pipe and, from your shell script, just echo commands to it.

Andrew Edgecombe
  • 39,594
  • 3
  • 35
  • 61
  • Named Pipe is safer. Signals has the drawback that from the time you learn the PID to the time you issue the `kill $PID` the system _could_ have reassigned that PID to a different process. Not likely, perhaps, but quite possible for a) you to learn your process' PID, b) your process to die, c) a new process to start and the d) OS to choose the PID you thought belonged to your process. making e) sending kill to that PID the wrong thing to do. – Jesse Chisholm Nov 12 '15 at 22:35
1

Since you also care about remote processes, and assuming you can modify the source code of all your programs, you could consider some way to communicate with them:

  • defining your own small textual protocol, and have each process listening on some socket or some named pipe. You probably would need some multiplexing syscall like poll

  • use existing libraries and tools like MPI, Corba, or perhaps D-Bus or ONC/RPC/XDR

  • change the configuration files of your application, and have signal conventions, e.g. catch SIGHUP to reload the configuration, and SIGTERM to properly terminate it (but there is no way to send a signal remotely; you'll need e.g. to ssh some kill command).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Option #3 (signals) has the drawback that from the time you learn the PID to the time you issue the `kill $PID` the system _could_ have reassigned that PID to a different process. Not likely, perhaps, but quite possible for a) you to learn your process' PID, b) your process to die, c) a new process to start and the d) OS to choose the PID you thought belonged to your process. making e) sending kill to that PID the wrong thing to do. – Jesse Chisholm Nov 12 '15 at 22:34