/usr/bin/sleep and SIGALRM
Akop Pogosian
version of sleep does exit when it recieves SIGALRM. Also, the Solaris
sleep(1) man page mantions that:
"NOTES
If the sleep utility receives a SIGALRM signal, one of the
following actions will be taken:
o Terminate normally with a zero exit status.
o Effectively ignore the signal.
The sleep utility will take the standard action for all
other signals."
However, it does not tell how to select one of these two options.
I'd like to do something like this in a bash shell script:
function alarm() {
/usr/bin/sleep $1
kill -SIGALRM $$
}
trap somefunction SIGALRM
alarm 60 &
while somecommand
do
another command
/usr/bin/sleep 10
done
Since the Solaris /usr/bin/sleep ignores SIGALRM, this code will not
work as intended on this OS. Is this the normal (e.g. POSIX standard?)
behavior?
--
Akop Pogosian
This space has been accidentally left blank.
Akop Pogosian
Oh, nevermind, the SIGALRM is sent to shell PID, not sleep program PID.
So, even if I used GNU sleep in this script, sleep wouldn't still exit
until it slept the specified amount of time. However, my question
about sleep behavior and SIGALRM still stands.
Scott Howard
> version of sleep does exit when it recieves SIGALRM. Also, the Solaris
> sleep(1) man page mantions that:
What are you trying to achieve? If you just want sleep to exit when you
send it a signal, use SIGTERM or SIGINT. It's generally not very nice
to go around sending SIGALRM and the like to processes - these are normally
signals which are used internally and are not intended as an external
interface.
Scott
Casper H.S. Dik
>function alarm() {
> /usr/bin/sleep $1
> kill -SIGALRM $$
>}
>trap somefunction SIGALRM
>alarm 60 &
>while somecommand
>do
> another command
> /usr/bin/sleep 10
>done
>Since the Solaris /usr/bin/sleep ignores SIGALRM, this code will not
>work as intended on this OS. Is this the normal (e.g. POSIX standard?)
>behavior?
First of all, you're not sending SIGALRM to "sleep"; you're sending
it to the shell.
The shell will catch SIGALRM but will then wait until sleep
exits before doign anything with it.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Kenny McCormack
Let's ignore the obvious typo in his posted code (this always happens).
There is historical precedence for using SIGALRM to prematurely terminate
the sleep command. Notes:
1) Up until recently, this worked. It is true that the standards
do not require it (i.e., do not require that sleep be implemented that way)
2) Sending it some other signal might cause it to exit with a
non-zero return code, causing some upstream process to think an error has
occurred (this was the context in which I first became aware of this problem)
The bottom line is that if you want the classical behavior, you'll have to
write your own version of sleep (which is really nothing more than an
invocation of the pause() syscall [*]). It can be done in about a dozen
lines of C (or about 2 lines of Perl).
[*] Don't bother to critique this statement. I know a) why it isn't
strictly correct, and b) why it is correct in my context.
Joerg Schilling
Kenny McCormack <gaz...@interaccess.com> wrote:
>There is historical precedence for using SIGALRM to prematurely terminate
>the sleep command. Notes:
> 1) Up until recently, this worked. It is true that the standards
>do not require it (i.e., do not require that sleep be implemented that way)
> 2) Sending it some other signal might cause it to exit with a
>non-zero return code, causing some upstream process to think an error has
>occurred (this was the context in which I first became aware of this problem)
>
>The bottom line is that if you want the classical behavior, you'll have to
>write your own version of sleep (which is really nothing more than an
>invocation of the pause() syscall [*]). It can be done in about a dozen
>lines of C (or about 2 lines of Perl).
What do you call 'classical' behavior?
sleep(1) calls atoi[argv[1]) and then calls sleep(3)
sleep(3) calls alarm() and pause().... It returns if SIGALRM arrives.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
Kenny McCormack
Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>In article <asvf97$r5h$1...@yin.interaccess.com>,
>Kenny McCormack <gaz...@interaccess.com> wrote:
>
>>There is historical precedence for using SIGALRM to prematurely terminate
>>the sleep command. Notes:
>> 1) Up until recently, this worked. It is true that the standards
>>do not require it (i.e., do not require that sleep be implemented that way)
>> 2) Sending it some other signal might cause it to exit with a
>>non-zero return code, causing some upstream process to think an error has
>>occurred (this was the context in which I first became aware of this problem)
>>
>>The bottom line is that if you want the classical behavior, you'll have to
>>write your own version of sleep (which is really nothing more than an
>>invocation of the pause() syscall [*]). It can be done in about a dozen
>>lines of C (or about 2 lines of Perl).
>
>What do you call 'classical' behavior?
>
>sleep(1) calls atoi[argv[1]) and then calls sleep(3)
>
>sleep(3) calls alarm() and pause().... It returns if SIGALRM arrives.
That *is* the classical behavior.
However:
1) Solaris (5.5.1) exhibits the classical behavior only when the
sleep time is small (I think up to 65535, but I haven't tested
exhaustively). Sleeps longer than that do not respond to SIGALRM.
2) Under Linux, observe:
(%) sleep 1000;echo $status
{send the process a SIGALRM from another window}
Alarm clock
142
(%)
Walter Briscoe
05:30:54 in comp.unix.shell, Akop Pogosian <akopps...@ocf.berkeley.e
du> writes
>In comp.unix.solaris Akop Pogosian <akopps...@ocf.berkeley.edu> wrote:
>> Solaris 8 /usr/bin/sleep ignores SIGALRM. I noticed that the GNU
>> version of sleep does exit when it recieves SIGALRM. Also, the Solaris
>> sleep(1) man page mantions that:
>
>> "NOTES
>> If the sleep utility receives a SIGALRM signal, one of the
>> following actions will be taken:
>
>> o Terminate normally with a zero exit status.
>
>> o Effectively ignore the signal.
>
>> The sleep utility will take the standard action for all
>> other signals."
copied from a standard document and describes how an implementation of
the sleep utility can behave. I believe the man page should describe how
sleep does behave rather than how it can. I am not surprised, the OP
thought there should be an interface to select between the behaviours. I
see no reason why such an interface should not be provided. However IEEE
Std 1003.1-2001 specifies no such interface. The Rationale says
> The exit status is allowed to be zero when sleep is interrupted by
> the SIGALRM signal because most implementations of this utility
> rely on the arrival of that signal to notify them that the requested
> finishing time has been successfully attained. Such implementations
> thus do not distinguish this situation from the successful
> completion case. Other implementations are allowed to catch the
> signal and go back to sleep until the requested time expires or to
> provide the normal signal termination procedures.
>
>> However, it does not tell how to select one of these two options.
>
>> I'd like to do something like this in a bash shell script:
>
>> function alarm() {
>> /usr/bin/sleep $1
>> kill -SIGALRM $$
>> }
>
>> trap somefunction SIGALRM
>> alarm 60 &
>> while somecommand
>> do
>> another command
>> /usr/bin/sleep 10
>> done
>
>> Since the Solaris /usr/bin/sleep ignores SIGALRM, this code will not
>> work as intended on this OS. Is this the normal (e.g. POSIX standard?)
>> behavior?
>
>Oh, nevermind, the SIGALRM is sent to shell PID, not sleep program PID.
>So, even if I used GNU sleep in this script, sleep wouldn't still exit
>until it slept the specified amount of time. However, my question
>about sleep behavior and SIGALRM still stands.
>
>
--
Walter Briscoe
Casper H.S. Dik
>However:
> 1) Solaris (5.5.1) exhibits the classical behavior only when the
> sleep time is small (I think up to 65535, but I haven't tested
> exhaustively). Sleeps longer than that do not respond to SIGALRM.
I've filed a bug to get the old ALRM behaviour restored for sleep.