Your message dated Sun, 19 Jun 2005 23:10:59 +0300
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #314727,
regarding login: suspend command from su shell fails to return to parent shell
to be marked as having been forwarded to the upstream software
author(s) Tomasz KÅ?oczko <[EMAIL PROTECTED]>.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---------------------------------------
Received: (at 314727-forwarded) by bugs.debian.org; 19 Jun 2005 20:03:47 +0000
>From [EMAIL PROTECTED] Sun Jun 19 13:03:47 2005
Return-path: <[EMAIL PROTECTED]>
Received: from cluster2.uol.ua (cluster1.uol.ua) [195.123.61.210] (root)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Dk61C-0008HA-00; Sun, 19 Jun 2005 13:03:47 -0700
Received: from [194.242.119.176] (account [EMAIL PROTECTED] HELO localhost)
by cluster1.uol.ua ( Ukraine Online SMTP 4.2.8)
with ESMTP-TLS id 22339740; Sun, 19 Jun 2005 23:23:21 +0300
Date: Sun, 19 Jun 2005 23:10:59 +0300
From: Alexander Gattin <[EMAIL PROTECTED]>
To: Tomasz =?utf-8?Q?K=C5=82oczko?= <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: Bug#314727: [Pkg-shadow-devel] Bug#314727: login: suspend command
from su shell fails to return to parent shell
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Hi!
On Sun, Jun 19, 2005 at 07:40:27PM +0200, Tomasz KÅ?oczko wrote:
> OK but you probaly also agree it is only kind of simptomatic cure.
>
> IMO using CLOSE_SESSIONS it is kind of "broken design" (in login and also
> in newgrp) and it must be solved by use only one variant of this code
> without use external login.defs::CLOSE_SESSIONS variable.
> Probaly on CLOSE_SESSIONS=yes is something missing in current code.
> Question is "what is missing ?".
Solution is being developed right now. Please follow
the thread to read my thoughts about the reason.
I think I have found a cure, which is applicable to
upstream, .i.e. it's not a kind of "quick dirty hack",
I hope.
I will add my explanations later, currently you can
read IRC log of my discussion with Nicolas on the
matter:
16:42 < xrgtn> the reasom is that with CLOSE_SESSIONS=yes
16:43 < xrgtn> we have su process _between_ parent she ll and child shell
16:43 < xrgtn> for example:
16:43 < xrgtn> 24943 pts/1 Ss 0:01 | \_ bash
16:43 < xrgtn> 7410 pts/1 S 0:00 | \_ su
16:43 < xrgtn> 7412 pts/1 S 0:00 | \_ bash
16:43 < xrgtn> 7415 pts/1 R+ 0:00 | \_ ps -A
f
16:43 < xrgtn> here I make `su` and in new shell run `ps -A f`
16:44 < xrgtn> pid 7410 is su
16:44 < xrgtn> and it's parent of child root shell (pid 7412)
16:44 < xrgtn> and child of parent shell (24943)
16:45 < xrgtn> So when 7412 stops 7410 gets control
16:45 < xrgtn> and not 24943.
16:45 < xrgtn> Do you follow?
16:45 < nekral_> yes
16:45 < xrgtn> When CLOSE_SESSIONS=no
16:45 < xrgtn> su doesn't create and _wait_ for child shell, just exec()s
16:46 < xrgtn> so child shell's image replaces 'su' image.
16:46 < xrgtn> And with CLOSE_SESSIONS=no there will be 'su' between 2 shells.
oops, here I wanted to say that there will be _no_ 'su'
between 2 shells ;)
16:47 < xrgtn> nekral_: IMHO there's no way to impement CLOSE_SESSIONS=yes
without having intermediate 'su' process.
16:48 < nekral_> That's also my opinion.
16:48 < xrgtn> But we could wor around the issue by "proxying" of "passing up"
the suspend.
16:48 < nekral_> I see what you mean.
16:49 < xrgtn> By handling child's suspend and suspending intermediate su then.
16:49 < xrgtn> We should ask Tomasz for his opinion on this.
16:49 < xrgtn> It's definitely appropriate for upstream.
16:49 < nekral_> Also the SIGCONT must be handled with the same kind of proxy.
16:50 < xrgtn> Yes -- we should pass it down. ;)
P.S. Currently the only problem for me to implement
this is all autoconf-related stuff like RETSIGTYPE
and alike.
--
WBR,
xrgtn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
