Unkillable jobs

Hi:

I have a logging system with some jobs that I want to always be running.
Rather than try to identify and handle all possible problems, I have
them stop on any errors and use tinit to restart them. My sysinit file
has a line like this:

tinit -c "on -f2 kmon ;sleep 30 " -t con2 -c “on -f2 navin ; sleep 30”
-t con3
-c "login halpenny " -t con1 con4 con5


This works well. The ‘sleep 30’ keeps the system from going into a
continuous restart mode in case of a recurring error.

My question is this: Is there any other way to do this? I want to make
some other tasks run continuously, and I will eventually run out of
consoles.

Thanks for your help.

John Halpenny

Assuming that you don’t need to send input to these apps,
you could just write a quick and dirty app that just
take a command line and sits in a loop something like:

while(1) {
retval=spawn*(P_WAIT, …)
sleep(30);
}

Then when ever the app exits it would restart. And if your
apps give back any usefull info in the return value, you
may even be able to build in some intellegence that can
fix things that cause your apps to die, or log that bad
things happened…

-Peter

John Halpenny <john.halpenny@geod.nrcan.gc.ca> wrote:

Hi:

I have a logging system with some jobs that I want to always be running.
Rather than try to identify and handle all possible problems, I have
them stop on any errors and use tinit to restart them. My sysinit file
has a line like this:

tinit -c "on -f2 kmon ;sleep 30 " -t con2 -c “on -f2 navin ; sleep 30”
-t con3
-c "login halpenny " -t con1 con4 con5



This works well. The ‘sleep 30’ keeps the system from going into a
continuous restart mode in case of a recurring error.

My question is this: Is there any other way to do this? I want to make
some other tasks run continuously, and I will eventually run out of
consoles.

Thanks for your help.

John Halpenny

pgraves@qnx.com wrote:

Assuming that you don’t need to send input to these apps,
you could just write a quick and dirty app that just
take a command line and sits in a loop something like:

while(1) {
retval=spawn*(P_WAIT, …)
sleep(30);
}

Then when ever the app exits it would restart. And if your
apps give back any usefull info in the return value, you
may even be able to build in some intellegence that can
fix things that cause your apps to die, or log that bad
things happened…

And, if you want to be even more complicated, you can handle
SIGCHLD to get notification and use wait() or family. They
will unblock with information about dieing children.

It gives you a bit more control than tinit – and doesn’t
require devices.

Of course, you can create extra devices… you can run Dev with
the -N command to create a new /Dev tree, and then run (say)
Dev.ditto -N/Dev/ditto to create some new devices there…
Dev.ditto gives a “console” that is not associated with keyboard
or screen, but you can ditto it to see what is happening.

-David

QNX Training Services
dagibbs@qnx.com

David Gibbs wrote:


,

Of course, you can create extra devices… you can run Dev with

the -N command to create a new /Dev tree, and then run (say)
Dev.ditto -N/Dev/ditto to create some new devices there…
Dev.ditto gives a “console” that is not associated with keyboard
or screen, but you can ditto it to see what is happening.

-David

QNX Training Services
dagibbs@qnx.com

This sounds like the best idea. My jobs try to avoid most error
conditions, but sometimes it is just easier to quit and be restarted
than to hope I can recover from all possible errors.

John