Debian Bug report logs - #346215
bash: a kill -TERM causes the EXIT trap to be executed

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: bash: a kill -TERM causes the EXIT trap to be executed

Date: Fri, 6 Jan 2006 14:33:33 +0100

Package: bash
Version: 3.1-1
Severity: normal

With the following script, "sh trapexitbug" and "bash trapexitbug"
cause the EXIT trap to be executed, which breaks traditional sh
compatibility and, IMHO, is not POSIX-compliant (see the explanations
in the script). Other shells, such as dash, ksh and zsh are not
affected by this problem.

----------------------------------------------------------------------------
#!/bin/sh

# Bug: With bash, a kill -TERM causes pterm to be executed.
#
# http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html says:
#     SIGTERM  T  Termination signal.
# and for T:
#     Abnormal termination of the process.  The process is terminated
#     with all the consequences of _exit() except that the status made
#     available to wait() and waitpid() indicates abnormal termination
#     by the specified signal.
#
# http://www.opengroup.org/onlinepubs/009695399/functions/_exit.html says:
#     The _Exit() [CX] and _exit() functions shall not call functions
#     registered with atexit() nor any registered signal handlers.

# Try the following:
#   sh trapexitbug
#   bash trapexitbug
#   dash trapexitbug
#   ksh trapexitbug
#   zsh trapexitbug

pterm()
{
  trap 0
  echo pterm
}

trap pterm 0
echo "PID = $$"
while true; do true; done

# $Id: trapexitbug 10633 2006-01-06 13:26:17Z lefevre $
----------------------------------------------------------------------------

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.4-20051215
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages bash depends on:
ii  base-files                    3.1.9      Debian base system miscellaneous f
ii  debianutils                   2.15.2     Miscellaneous utilities specific t
ii  libc6                         2.3.5-11   GNU C Library: Shared libraries an
ii  libncurses5                   5.5-1      Shared libraries for terminal hand

bash recommends no packages.

-- no debconf information

Message #10 received at 346215@bugs.debian.org (full text, mbox, reply):

From: bob@proulx.com (Bob Proulx)

To: Vincent Lefevre <vincent@vinc17.org>

Cc: bug-bash@gnu.org, 346215@bugs.debian.org

Subject: Re: a kill -TERM causes the EXIT trap to be executed

Date: Thu, 26 Jan 2006 23:34:31 -0700

Vincent Lefevre wrote:
>   An EXIT trap is executed when the process is killed, e.g. by the
>   SIGTERM signal, which breaks traditional sh compatibility

A lot of POSIX required behavior breaks traditional Bourne sh
compatibility.

>   and, IMHO, is not POSIX-compliant (see the explanations in the
>   script below).  Other shells, such as dash, ksh and zsh are not
>   affected by this problem.

ksh handles this the same way as bash.  Perhaps you tested with pdksh?

>   With the following script, "sh trapexitbug" (under Linux) and
>   "bash trapexitbug" cause the EXIT trap to be executed.

It has been a long time POSIX shell requirement that the EXIT trap is
executed upon shell exit regardless of why that shell exited.  This is
intentional.

Note that in addition to bash that HP-UX /bin/sh and /bin/ksh both
execute the EXIT trap upon receiving SIGTERM.  I imagine that other
systems behave this way too.  Changing this would break compatibility
with many scripts.  This has been relied upon for a long time.

> # http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html says:
> #     SIGTERM  T  Termination signal.
> # and for T:
> #     Abnormal termination of the process.  The process is terminated
> #     with all the consequences of _exit() except that the status made
> #     available to wait() and waitpid() indicates abnormal termination
> #     by the specified signal.
> #
> # http://www.opengroup.org/onlinepubs/009695399/functions/_exit.html says:
> #     The _Exit() [CX] and _exit() functions shall not call functions
> #     registered with atexit() nor any registered signal handlers.

That is the default action.  But once you set an EXIT trap you change
the default action to the one specified in the trap.  So those
requirements no longer apply.

I believe bash (and ksh too) is behaving correctly here.

Bob

Message #15 received at 346215@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.org>

To: Bob Proulx <bob@proulx.com>

Cc: bug-bash@gnu.org, 346215@bugs.debian.org

Subject: Re: a kill -TERM causes the EXIT trap to be executed

Date: Fri, 27 Jan 2006 14:47:27 +0100

On 2006-01-26 23:34:31 -0700, Bob Proulx wrote:
> Vincent Lefevre wrote:
> >   An EXIT trap is executed when the process is killed, e.g. by the
> >   SIGTERM signal, which breaks traditional sh compatibility
> 
> A lot of POSIX required behavior breaks traditional Bourne sh
> compatibility.

I know, but if it is not a POSIX requirement, it is annoying to
break the Bourne sh compatibility.

> >   and, IMHO, is not POSIX-compliant (see the explanations in the
> >   script below).  Other shells, such as dash, ksh and zsh are not
> >   affected by this problem.
> 
> ksh handles this the same way as bash.  Perhaps you tested with pdksh?

OK, here are my latest tests:

# Results on Linux/x86 (Debian):
#   Shell   Version     pterm executed?
#   -----------------------------------
#   bash    3.1.5(1)    yes
#   sh      (bash)      yes
#   dash    0.5.3       no
#   ksh93   1993-12-28  yes
#   mksh    R25         no
#   pdksh   5.2.14      no
#   zsh     4.3.0-dev-2 no
#
# Under other systems:
#   OS / Shell          pterm executed?
#   -----------------------------------
#   SunOS 5.7           yes (/usr/xpg4/bin/sh)
#   OSF1 4.0            yes (/usr/bin/posix/sh)
#   FreeBSD 5.4 (=dash) no
#   NetBSD 3.0 (=dash)  no
#   HP-UX B.11.11       yes

Note: I know that dash is not POSIX yet.

> >   With the following script, "sh trapexitbug" (under Linux) and
> >   "bash trapexitbug" cause the EXIT trap to be executed.
> 
> It has been a long time POSIX shell requirement that the EXIT trap is
> executed upon shell exit regardless of why that shell exited.  This is
> intentional.

Does anyone has some *clear* reference about that? After re-reading
some parts of POSIX, it appears that it is not clear. POSIX says that
the "exit" utility causes the trap on EXIT to be executed before the
shell terminates (except when the exit utility is invoked in that trap
itself). But it doesn't seem to say more.

Also concerning the "regardless of why that shell exited", the EXIT
trap cannot be called if the shell terminates due to a SIGKILL. From
this point of view, what you said cannot be completely correct.

> > # http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html
> > # says:
> > #     SIGTERM  T  Termination signal.
> > # and for T:
> > #     Abnormal termination of the process.  The process is terminated
> > #     with all the consequences of _exit() except that the status made
> > #     available to wait() and waitpid() indicates abnormal termination
> > #     by the specified signal.
> > #
> > # http://www.opengroup.org/onlinepubs/009695399/functions/_exit.html says:
> > #     The _Exit() [CX] and _exit() functions shall not call functions
> > #     registered with atexit() nor any registered signal handlers.
> 
> That is the default action.  But once you set an EXIT trap you change
> the default action to the one specified in the trap.  So those
> requirements no longer apply.

This is the default action for SIGTERM. But concerning _exit,
I haven't seen that it was a default action. Could you give
more details or do you have a precise reference?

A last point: If POSIX allows the current behavior, when should
the signal be taken into account? I give an example below to make
my question clearer:

pterm()
{
  trap 0
  echo "pterm: $foo"
}

trap pterm 0
echo "PID = $$"
while true; do read foo; printf "%s\n" "$foo"; done

Currently, the TERM signal interrupts the read built-in.
But what if $foo was being modified when the signal occurs?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Send a report that this bug log contains spam.