Your message dated Wed, 18 Nov 2015 19:59:46 +0100 with message-id <[email protected]> has caused the report #805417, regarding Dtach leaves signals ignored in slave process. to be marked as having been forwarded to the upstream software author(s) [email protected]
(NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 805417: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805417 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Hi, please keep at least [email protected] on CC to record your messages to the Debian Bug Tracker, thanks. Stefan ----- Forwarded message from Robert de Bath <[email protected]> ----- Date: Tue, 17 Nov 2015 22:38:27 +0000 (GMT) From: Robert de Bath <[email protected]> To: [email protected] Subject: Bug#805417: Dtach leaves signals ignored in slave process. User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-Mailer: Alpine for Linux 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/> ----- End forwarded message ----- -- BOFH excuse #234: Someone is broadcasting pygmy packets and the router doesn't know how to deal with them.
--- End Message ---
