Package: dtach
Version: 0.8-2.1
On a 'dtach'ed shell
$ grep Sig /proc/self/status
SigQ: 2/48068
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001001
SigCgt: 0000000180000000
$
Expected result, eg running under ssh or an XTerm:
$ grep Sig /proc/self/status
SigQ: 0/62981
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000000
$
Converting the SigIgn to binary
00001000000000001000000000001
98765432109876543210987654321
22222222221111111111
Signal 1 -> SIGHUP
Signal 13 -> SIGPIPE
Signal 25 -> SIGXFSZ
This means that processes within a pipeline will ignore the SIGPIPE
that's supposed to terminate them when the process at the end of the
pipeline finishes early and, if programmed correctly, they will complain
about an I/O error on writing to their stdout.
Resetting the signal() to SIG_DFL in the child, just before exec(), does
NOT seem to work.
Trapping the signals that are ignored in dtach and routing them to a
no-op handler appears to give the required semantics.
But the simplest solution/workaround seems to be to move the
signal(SIGxxx, SIG_IGN)
calls after the call to init_pty() so that the signals are not actually
ignored when the child is forked off.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>
