From owner-freebsd-questions Fri Dec 1 10:14:25 2000 Delivered-To: freebsd-questions@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id 68E8737B400 for ; Fri, 1 Dec 2000 10:14:21 -0800 (PST) Received: from [212.238.77.116] (helo=buffy.raggedclown) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 141uhI-00009I-00; Fri, 01 Dec 2000 18:14:13 +0000 Received: from localhost (localhost [[UNIX: localhost]]) by buffy.raggedclown (8.10.2/8.10.2) id eB1ICP504060; Fri, 1 Dec 2000 19:12:25 +0100 From: Cliff Sarginson Date: Fri, 1 Dec 2000 19:12:22 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" To: Vlad Skvortsov , freebsd-questions@freebsd.org References: <20001201010421.A68505@high.net.ru> In-Reply-To: <20001201010421.A68505@high.net.ru> Subject: Re: dup2/pipe issue MIME-Version: 1.0 Message-Id: <00120119122201.02179@buffy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday 30 November 2000 23:04, Vlad Skvortsov wrote: > Hello ! > > My apologize if this is not correct list to ask such questions. > It isn't I guess.. > > /* to_us and from_us are pipes to and from our process, > 0th element is read end, 1st - write end. > sd is connected socket. > */ > > close (from_us[0]); > close (to_us[1]); > > dup_sock = dup (sd); > dup_out = dup (from_us[1]); > dup_in = dup (to_us[0]); > dup2 (dup_in, 0); > dup2 (dup_out, 1); > dup2 (dup_sock, 2); > > /* Child won't need anything except fds 0-2 */ > for (i = 3; i < file_descriptors_table_size; i ++) > close (i); Gut reaction.. The very first thing you should do is to comment out the closes above and then test it. They are not functionally needed, and complicate the issue. I will look at it further when I get time.. and respond if I have anything useful... > /* Clear close-on-exec flags for fds 0-2 */ > ... > > /* Exec the app */ > ... > > All dup/dup2 calls are successfull. But when parent tries writing to > the pipe it receives SIGPIPE. Debugging shows that the pipe gets widowed > after the last dup2 call. Let's see what happens. Up to this points there > are following allocations of file descriptors: > > /* l - socket that daemon listens on > a - socket with accepted connection > s - syslog socket > f[0] - from_us[0] - read end of outgoing pipe > f[1] - from_us[1] - write end of outgoing pipe > t[0] - to_us[0] - read end of incoming pipe > t[1] - to_us[1] - write end of incoming pipe > */ > > l : 0 > a : 1 > s : 3 > f[0]: 5 > f[1]: 6 > t[0]: 2 > t[1]: 4 > > close (from_us[0]); > close (to_us[1]); > l : 0 > a : 1 > s : 3 > f[1]: 6 > t[0]: 2 > > dup_sock = dup (sd); > l : 0 > a : 1 4 > s : 3 > f[1]: 6 > t[0]: 2 > > dup_out = dup (from_us[1]); > l : 0 > a : 1 4 > s : 3 > f[1]: 6 5 > t[0]: 2 > > dup_in = dup (to_us[0]); > l : 0 > a : 1 4 > s : 3 > f[1]: 6 5 > t[0]: 2 7 > > dup2 (dup_in, 0); > a : 1 4 > s : 3 > f[1]: 6 5 > t[0]: 2 7 0 > > dup2 (dup_out, 1); /* (1) */ > a : 4 > s : 3 > f[1]: 6 5 1 > t[0]: 2 7 0 > /* The pipe is still functioning here (all FDs: 0, 2 and 7) */ > > dup2 (dup_sock, 2); /* (2) */ > a : 4 2 > s : 3 > f[1]: 6 5 1 /* outgoing pipe */ > t[0]: 7 0 /* incoming pipe */ > /* The pipe appears to be broken after this call (neither FD 0, nor 7) */ > > Two things to mention here. > > The outgoing pipe is okay. The only difference in setting up FD1 and > FD0 is that when setting up outgoing pipe (FD1) no dup2 calls freed any of > FDs associated with pipe. On the other side when setting up incoming pipe, > dup2 call marked as (2) freed descriptor 2 associated with this pipe and > has broken the pipe down. Closing any descriptors associated with pipe > using close(2) call doesn't break pipe. > > The second thing is that dup2 doesn't break _socket_ even freeing > descriptor associated with it (dup2 call marked as (1)). > > Can anyone point me to the direction how to debug/solve the problem ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message