User Defined Signal 1

[KapilRaj]

Hi ,

Anyone has faced this error ? what is this , I get this error for some of my backup sessions which runs thru a scheduler.

They fail with RC158 : User Defined Signal 1

Regds,

Kaps

[Stephen Keane]

It means the application has received SIGUSR1, which is a signal that is not normally raised by o/s executables. It's the sort of signal that is raised by user executables. You can raise it by killing the executable thus

kill -16 pid

Or

kill -USR1 pid

I suspect the scheduler is sending the signal, perhaps it means something to the scheduler, but the backup session doesn't understand it (i.e. trap it) , so it fails.
I've seen SIGUSR1 and SIGUSR2 used for raising/lowering logging levels for example.

[KapilRaj]

That was a good one .. can I have more views please ?

Regds, Kaps

[Bill Hassell]

There is no way to determine what the problem is because it is unique to your backup program. With dozens of backup utilities that are completely incompatible with each other, this can only be solved by the program's designer(s). We can guess that signal 16 (SIGUSR1) has been seen by some process but how and why this happened cannot be determined by the cryptic message. Does the backup program's documentation have any details?

[KapilRaj]

I started a backup session manually and tried to kill using kill -USR1 and -16 but it did not fail. So that means my backup program ignore this signal.

But when I tried on one of my shell scripts ( I use Ksh in aix)
while true
do
echo kaps
sleep 10
done

IT Failed with "User Defined Signal 1 " , Any idea how I can trap this signal in my shell scripts ?.

The backup program is driven by a shell script .

Regds,

Kaps

[A. Clay Stephenson · Accepted solution]

To ignore the SIGUSR1 signal, you simply need to add trap '' 16 to your shell script. The important point is that this signal is not coming out of the blue; a process must be generating this signal. It could even be the backup process itself; it's perfectly legal for a process to send a signal (via the kill() system call) to itself.

[KapilRaj]

Thanks Clay ,

Infact I just read the following page and did it already

http://www.cons.org/cracauer/bourneshell.html

Regds,

Kapil

[KapilRaj]

As I said the backup program ignores that signal .. I tried it by sending a kill -USR1 on to the backup process . It did nothing but for the shell script it failed with RC158 "User Defined Signal 1"

Regds,

Kapil

[Biswajit Tripathy]

Kapil,

While you are at it, you might want to trap
SIGUSR2 too. Both SIGUSR1 and 2 serve exactly
same purpose, i.e user defined signals for use
when a process wants to send a signal to another
(or same) process for an event. The default
behaviour of a process when it receives SIGUSR1
and 2 is to terminate itself unless the process has
a handle for the signals.

Also you might want to findout the origin of the
signal because, as A. Clay Stephenson said, it is
not coming out of blue.

- Biswajit

[KapilRaj]

Good one again .. Thanks. I am not planing to do it now i will do it later.

Infact the scene here is quite complex to investigate ..

For backup job, we have a scheduler ==> sysadmin script === > oracle script , the oracle script put each tblspace to hot-backup mode and then use sudo to issue the backup process for the datafiles .. Even sudo has a covering script.

Now I need to find who in this chain is likely to issue a USR1. I think it might be the scheduler as rest are all shell scripts which we or the dba's have written.

Regds,

Kapil

[KapilRaj]

Any more ideas or experiences with this error.

Kaps