UNIX for Advanced & Expert Users

I want to know the interrupt passed to a process through 'ulimit'

I am running a process which gets killed when the 'ulimit -t' reaches.
But after killing the process I want to start another process which would
send a message or do some clean up or anything at all.

To do the same I am using 'trap' and a function call, which does, rest of the
activity (mailing, cleanup, etc). But the problem is using the interrupt signal for trap.

I have tried using all from 1 to 38 which are mentioned in the "/usr/include/sys/iso/signal_iso.h" file.
But those signals are not what 'ulimit' sends to kill a running process on the system.
On the other hand what i observed was if "0" is used with trap, then the ulimit interrupt
is trapped and I am able to run the over head function in trap. But using 0 does not make
sense. And i have also not found any reference for the same mentioned anywhere.

In addition to the same. I tried using 'truss' to give me information as to which interrupt
is sent to my running process and truss shows that it is "/2: Received signal #30, SIGXCPU [default]"
But if i use 'trap' with 30 .. it still does not help.

Any ideas as to what kind of interrrupt does 'ulimit' send to a process and how can one trap the same.

To give u a sample of the code I am using. Please refer to the following example.

#!/bin/ksh

trapme(){
echo "stoppid me"
touch haha.$$
}

callmain(){

trap 'trapme' 30
truss find ./ -name "*signal*" | grep "_iso" | grep ".h" 1> tempout.$$ 2> temperr1.$$
}

callmain

SIGXCPU is the right signal. You can bet that ksh gets it. But ksh does not make all signals available to the script for direct manipulation. trap 0 is invoked whenever a script exits for any reason.

Make this two scripts, a monitor script and the real script. The real script will touch a flag file when it starts. If it finishes normally it removes the flag file. The monitor script will run the real script. Then it sends mail if the flag file exists.

Or rewrite the script in C. Then you can access every signal.

Okie I have gone forward and done some more research on the same.
Your idea of using C shell is very true and it works. But I guess I won't be able to use the same.

As long as the signal getting passed to korn shell is concerned here is my analysis.

If i use the following script,

==================================================
#!/bin/ksh

ulimit -t 1

trap 'echo "CPU time limit exceeded"; exit 2' XCPU
num=1
while true
do
echo $num >> haha
num=`expr $num + 1`
done


Output:
asakpal[/export/home/asakpal] ksh r.sh
CPU time limit exceeded
asakpal[/export/home/asakpal] echo $?
2
asakpal[/export/home/asakpal]

==================================================

then the trap works fine and it does what it's supposed to do.
Basically this argument refutes the fact that
"But ksh does not make all signals available to the script for direct manipulation."

But on the other hand if i use this following script.

==================================================
#!/bin/ksh

ulimit -t 1

trap 'echo "CPU time limit exceeded"; exit 2' XCPU

find / -name "*haha*" 2> /dev/null


Output:

==================================================

then I get a core dumped error. But I still do not get a my echo message.


What baffles me is that for one type of execution trap works while for other it doesn't. Any more ideas

Apologies... i happened to send the post without giving the output for the failure of trap.

It goes like this.

==================================================
#!/bin/ksh

ulimit -t 1

trap 'echo "CPU time limit exceeded"; exit 2' XCPU

find / -name "*haha*" 2> /dev/null


Output:
asakpal[/export/home/asakpal] ksh f.sh
f.sh[17]: 13404 Cpu Limit Exceeded
asakpal[/export/home/asakpal] echo $?
158
asakpal[/export/home/asakpal]

==================================================

Your analysis is very interesting. The problem is that you are thinking of the shell script as a single unit but to the kernel it is a collection of processes. In your first case you used nothing except ksh built-in commands. In this case, ksh itself exceeded the one second limit. But in the second case ksh did not use a full second. It was "find" that ran too long. The find process got a signal and was killed. After the death of the find command, ksh continued to run. But it ran to completion without consuming a full second of cpu time.

OK what you say makes sense and it does work the way you have mentioned. But I really don't understand why would a function like 'trap' would be built if it ends up working the way it does.

I don't understand why the signal interrupt sent to the child process is not passed back to the parent process. (As 'trap' forms a part of the parent process and not the child process). If the interrupt was sent to the parent then it would have got trapped and everything would have been good.
Tried getting this information but couldn't get to the crux of the matter.
These signal commands I gather can do a lot of manipulation. But i am lacking in that area.

The solution as i have found out to trapping the signal interrrupt and going in the overlib function is to use 'timex -opf' option. This adds a return code from the "command" which was being used, which inturn got the interrupt, and hence the STAT column in 'timex -opf' gets set to a non zero value to indicate that it was an interrupt and an error.
You may ask why not use the return code from the command directly. But the obvious answer being, will not know whether the error was because of interrupt or beacuse of some valid error. Also if timex -op needs to be used inherently then signal interrupt sent to the command terminates the command and timex -op by itself being a independent child process executes sucessfully with 0 return code.

basically.. think of the following command getting a signal interrupt coz of 'ulimit -t 1' and how will one be able to capture the same to go in overlib.

timex -op find / -name "*haha*" 1> tempout.$$ 2> temperr.$$


This does help me solve my problem, but me not happy with not being able to used 'trap' directly. Oh well.. lets see.

Anyways thanx Perderabo.