From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11910 invoked by alias); 17 Dec 2014 06:27:50 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33985 Received: (qmail 25806 invoked from network); 17 Dec 2014 06:27:48 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=PYxIXZlY c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=OnffnoNZBRefWZzfwtMA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141216222752.ZM19425@torch.brasslantern.com> Date: Tue, 16 Dec 2014 22:27:52 -0800 In-reply-to: Comments: In reply to Chirantan Ekbote "Bug in interaction with pid namespaces" (Dec 16, 3:07pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Chirantan Ekbote , zsh-workers@zsh.org Subject: Re: Bug in interaction with pid namespaces MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 16, 3:07pm, Chirantan Ekbote wrote: } } I think I've found an issue with the way zsh interacts with pid } namespaces [1]. Specifically the problem is that when zsh is launched } immediately following the creation of a new pid namespace it doesn't } take ownership of the process group, causing things like SIGINT to be } sent to the process that spawned zsh rather than zsh itself. Considering that pid namespaces are a very recent invention compared to zsh, this is hardly surprising. It was never meant to be used as a replacement for init. } The expected result is that the pgid for zsh should be the same as its } pid, indicating that zsh has become the leader of a new process group. } Instead I see that zsh has pgid 0 and a different pid (usually 1). How often is it not 1 ? The first process in the namespace should always get pid 1, if I'm reading correctly. Nevertheless ... } I think this can be fixed with the following patch: } } - if ((mypgrp = GETPGRP()) > 0) { } + if ((mypgrp = GETPGRP()) >= 0) { I don't see any reason not to make that change ... } but this brings up another problem. When zsh exits it tries to restore } the original process group using setpgrp(0, origpgrp). This is an } issue when origpgrp is 0 because setpgrp(0, 0) actually means "set the } process group of the calling process to be the same as its pid" I'm not familiar enough with pid namespaces to answer authoritatively, but my understanding is that when the first process in the namespace exits, the entire namespace ceases to exist -- sy why does this matter at all? The pgrp should already be the same as the pid at that point, and the whole point of the namespace is that processes inside the namespace can't directly reference a pid or pgrp outside the namespace, so setpgrp(0,0) should be unnecessary but a no-op. What's the actual problem that's left over after zsh has exited?