Hello all!

I'm writing a script that will catch when an outside process crashes (SIGHUP, right?) without having to loop into infinity.
With that in mind, I came across the trap utility and thought if could be used to monitor another process other than it's own. But from what I've read, I'm thinking it might be more limited than what I initially believed.

Could someone point me in the right direction?

This is what I have on trap so far:
http://linux.die.net/man/1/trap
http://tldp.org/LDP/Bash-Beginners-G...ect_12_02.html

hmm well.

I've played an awful lot with trap in the past.
I've used it so much that I rarely bother with it now.
it's ok for EXIT.

you can't catch a signal from another process - full stop.
they don't propogate.

the shell trap system is very very weak.
for instance they ain't inherited by functions in the same script.
remember shell scripting has limits.

if you look at waitpid(3) you'll see that there is a bitmask
which shows how the process exited. I'm not sure if this can be
examined in a shell with the $?.
on my system NOHUP produces 129, TERM = 127 so maybe it can.

the perl system allows you to query it.
or write a little C program to run it.

So if I use waitpid, the process I'm watching out for crashes needs to be a child process of the script?

no, waitpid is a C function.

and SIGHUP is not a crash.

what exactly are you trying to achieve?

Here it is:

This script will start by starting another process.
It will grab it's PID using pgrep
Then I want it to wait until the process it started at the beginning has crashed or not.
When it crashes, I want the script to restart the process.
Otherwise, keep waiting for it to crash.

Concise enough? Let me know if I got vague anywhere.

Hi

It could be done easily without pids, signals or traps. But you will have to figure out what is a crash and what is a normal exit. If the process writes some pid file or something you could maybe just check if it still exists?

Why not just:

You said before But I can't see why a loop is bad here. If by crash you mean only termination from SIGHUP, maybe what you want here is nohup?

We'll I'd be a fool not to toy around with what I've been given.
As far as loops go, I though if it was constantly checking for a contingency it would run the processor into the ground.

Thinking about it, that was silly to think that would be the case in this situation. But we'll see. I likely need to employ the rule of optimization more rather than trying to get it 100% right the first few time.

Also adderek on unix.com suggested I use fork to make the program a child process, and monitor it that way. Does fork have unintended consequences/issues?

The processor thrashing issue depends on how soon after a failure you need(!) the program to restart.
If you can manage for a few minutes, then you could use cron to run a watchdog script that checks/restarts the program every n minutes.

Or you could put a sleep in the loop.

what is this vital program?

out of interest.

An RPG game server.
Keep the daemon up, keep the players from squawking too loudly.
The whole concept for this I got from my father explaining to me his wastewater SCADA system he's been working on for the better part of a decade.
While he's not the developer, just the end-user and a wastewater supervisor at a small town's public works, the idea fit for UNIX system control.
And yes, I have heard of webmin. I just love my shell much much more.

But the bigger picture is eventually I'd like to code this in a C language, and go much larger and much more extensible. Checking the system for errors, anticipating and fixing problems, and communication to the sysop on duty. (I got sendmail working, yay!)
But for prototyping, I'll stick with bash. She's been good to me.

Maybe this, just to be safe:Kevin Barry

I did some digging and came up with this.

Gonna play with some more functions...