Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14074 > unrolled thread
| Started by | Andrei Vagin <avagin@virtuozzo.com> |
|---|---|
| First post | 2018-05-01 09:44 -0700 |
| Last post | 2018-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.
Re: [PATCH] A terminating signal has to complete a bash process Andrei Vagin <avagin@virtuozzo.com> - 2018-05-01 09:44 -0700
| From | Andrei Vagin <avagin@virtuozzo.com> |
|---|---|
| Date | 2018-05-01 09:44 -0700 |
| Subject | Re: [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/
Back to top | Article view | gnu.bash.bug
csiph-web