From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28898 invoked by alias); 17 Dec 2014 16:54:13 -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: 33992 Received: (qmail 6368 invoked from network); 17 Dec 2014 16:54:11 -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=CoYIqc8G 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=jK86WyKsdjcoAqAQkysA:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141217085435.ZM545@torch.brasslantern.com> Date: Wed, 17 Dec 2014 08:54:35 -0800 In-reply-to: Comments: In reply to Chirantan Ekbote "Re: Bug in interaction with pid namespaces" (Dec 16, 11:50pm) References: <141216222752.ZM19425@torch.brasslantern.com> 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, 11:50pm, Chirantan Ekbote wrote: } } We're not trying to use zsh as a replacement for init. I first noticed } this issue because the chrome os build system recently switched to } using pid namespaces in the build chroot. [...] In the actual workflow } where this is an issue for me, the pid is somewhere in the 240 to 270 } range and zsh is only meant to behave like a regular shell. OK, so the issue is that zsh is started as a (possibly indirect) child of whatever was given "leadership" of the namespace, but at the time zsh starts GETPGRP() == 0. That sounds like a bug in one of the ancestor processes, then, because shouldn't whatever *that* is, have become a group leader, or assigned the process group to the fork() pid before execve() of zsh? } > } - if ((mypgrp = GETPGRP()) > 0) { } > } + if ((mypgrp = GETPGRP()) >= 0) { } > } > I don't see any reason not to make that change ... } > } } Excellent. Should I re-send it as a proper patch? No need, I already applied it and pushed it to the repository. } So the problem is that on exit zsh gives a warning: } } zsh: can't set tty pgrp: no such process } } which I thought was due to the call to setpgrp() but is actually in } the call to attachtty(). Aha. That means that one of tcsetpgrp(SHTTY, pgrp) or arg = &pgrp ioctl(SHTTY, TIOCSPGRP, &arg) is returning -1 and errno == ESRCH. Which makes sense if pgrp == 0. But that also means that zsh is being invoked as an interactive shell, because attachtty() is a no-op otherwise. I can't imagine why the chrome os build would need to run an interactive shell. However, I suggest the following. The mypgrp = origpgrp assignment is questionable because the pgrp won't actually have been changed, but it may help elsewhere in tests that mypgrp != GETPGRP(). Shell exit is not the only place where release_pgrp() is called. diff --git a/Src/jobs.c b/Src/jobs.c index 8c4254a..c6e1bce 100644 --- a/Src/jobs.c +++ b/Src/jobs.c @@ -2779,8 +2779,11 @@ void release_pgrp(void) { if (origpgrp != mypgrp) { - attachtty(origpgrp); - setpgrp(0, origpgrp); + /* in linux pid namespaces, origpgrp may never have been set */ + if (origpgrp) { + attachtty(origpgrp); + setpgrp(0, origpgrp); + } mypgrp = origpgrp; } }