http://bugs.grommit.com/show_bug.cgi?id=571
Summary: AST sleep SIGALRM behavior incompatible with Solaris
/usr/bin/sleep
Product: ksh93-integration
Version: unspecified
Platform: All
OS/Version: Solaris 11/Nevada
Status: NEW
Severity: blocker
Priority: P3
Component: App/ksh93
AssignedTo: ksh93-integration-discuss at opensolaris.org
ReportedBy: april.chin at sun.com
CC: ksh93-integration-discuss at opensolaris.org
In the next ksh93 update in Solaris, the ksh93 built-in sleep will be replacing
Solaris /usr/bin/sleep.
Solaris /usr/bin/sleep will catch the SIGALRM but do nothing. The sleep
continues and effectively ignores the signal, eventually exiting with
status 0.
The AST ksh93 built-in sleep will do the default action for SIGALRM:
it terminates and exits with 142 (128 + 14 (the signal # for SIGALRM).
Although both behaviors are allowed by the standard, the differing
behavior will be an incompatibility when ksh93 sleep replaces
Solaris /usr/bin/sleep.
Discussion with Don Cragun brought up these points:
The below known case will behave differently with ksh93 built-in sleep versus
Solaris sleep if a SIGALRM is delivered to sleep:
while sleep 10
do
__something__
done
Also, many users may expect sleep to exit 0, given that the
standard (and Solaris sleep(1) manpage) state that an exit
status of 0 is returned if the execution was successfully
suspended for at least <time> seconds or a SIGALRM signal was
received. The standard goes on to refer to the ASYNCRHONOUS
EVENTS section, but this may be missed by users.
Recommend that we change the SIGALRM behavior of AST sleep to match that
of Solaris /usr/bin/sleep before replacing Solaris /usr/bin/sleep.
--
Configure bugmail: http://bugs.grommit.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
You are the assignee for the bug, or are watching the assignee.
