Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14074 > unrolled thread

Re: [PATCH] A terminating signal has to complete a bash process

Started byAndrei Vagin <avagin@virtuozzo.com>
First post2018-05-01 09:44 -0700
Last post2018-05-01 09:44 -0700
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] A terminating signal has to complete a bash process Andrei Vagin <avagin@virtuozzo.com> - 2018-05-01 09:44 -0700

#14074 — Re: [PATCH] A terminating signal has to complete a bash process

FromAndrei Vagin <avagin@virtuozzo.com>
Date2018-05-01 09:44 -0700
SubjectRe: [PATCH] A terminating signal has to complete a bash process
Message-ID<mailman.13225.1525207527.27995.bug-bash@gnu.org>
On Tue, May 01, 2018 at 10:40:18AM -0400, Chet Ramey wrote:
> On 4/30/18 6:05 PM, Andrei Vagin wrote:
> > bash sets a handler for all terminating signals, which saves history,
> > executes traps, sets a default signal handler and re-sends the same
> > signal to itself. It expects that this signal will kill it.
> > 
> > Unfortunately it doesn't work in Linux, when a bash script is executed as
> > an init process in a pid namespaces, because all signals to the init
> > process, what are sent from the current pid namespace, are ignored.
> > 
> > man 7 pid_namespaces
> >   Only signals for which the "init" process has established a signal han‐
> >   dler can be sent to the "init" process by  other  members  of  the  PID
> >   namespace.   This restriction applies even to privileged processes, and
> >   prevents other members of the PID namespace from  accidentally  killing
> >   the "init" process.
> > 
> > Chet Ramey suggested to add a call to exit() after the kill(). This
> > patch adds this call for signals, which do not result in a core dump.
> > For other signals, a null pointer is dereferenced to get a core file.
> 
> What's the value of a core dump from a different signal in this case?

If we get these signals from kernel, it means that we have a bug. A core
dump can be usefull to investigate it. Modern linux distributions
automatically detect code dump files, and generates a bug report with
all required information.

> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> 		 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web