Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 214
  • Last Modified:

Programs launcher/monitor

Hi there!, I have a set of programs (1..6) let me refer them as "services" wich I need to execute all in the same shell because they use a common PATH, and in the same machine (SUN-Solaris) run the services again but with another PATH.
The status is 2 or 3 sessions within its PATH and running this services, well the problem is that I can't control (stop, restart) only 1 program inside a service because they all have the same name but in different instances.
The idea is write a program wich forks or execs this programs from a conf file, and write the PID somewhere in order to kill and restart later 1 program of a service of a session:
 Graphical explanation:

Services = {  PgmA , PgmB , PgmC,... }
Session=  { SrvA , SrvB , SrvC , ... } where SrvA={PgmA, PgmB} ...

And I will launch different Sessions within its services and programs.

0
trickle
Asked:
trickle
1 Solution
 
jlevieCommented:
If modifying the source of your "services" is an option, the cleanest solution would be to have each of them get their pid on startup and emit it to stdout. Your start script could then get the value and save it however you wish.
0
 
chris_calabreseCommented:
I shouldn't think that even that is necessary.  When the startup program executes the service program it knows the pid.

I'll assume the startup program is written as a sh script as you mentino the shell.  In this case, the PID of the last program spawned is held in $!, so you code would look something like this:

  session_id=a
  PATH="$PATH_a" service_program_a service_args ... &
  echo "$!" > "/my/path/pid.$session_id"

though perhaps a bit more complex if you want to group the different programs together by session or something like that.

If you're doing it in C, it's a bit more tedious becouse you need to do all the fopen's and such, but you still get the pid's from the fork() return value, so it's not that bad.  I'd definitly go with shell, as you won't need an external configuration file (the script will be small enough to have all its own config inormation).
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now