Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 704498 - FEATURES=pid-sandbox - SIGTSTP does not stop all children
Summary: FEATURES=pid-sandbox - SIGTSTP does not stop all children
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 751493 (view as bug list)
Depends on: 675870
Blocks:
  Show dependency tree
 
Reported: 2020-01-01 20:34 UTC by Jeroen Roovers (RETIRED)
Modified: 2022-03-30 16:28 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeroen Roovers (RETIRED) gentoo-dev 2020-01-01 20:34:41 UTC
For a while now I have seen that a SIGSTOP of an emerge process fails to stop all children - various new jobs are still spawned despite the parent being stopped. When I set FEATURES=-pid-sandbox, the problem goes away.
Comment 1 Zac Medico gentoo-dev 2020-01-01 23:41:08 UTC
It's triggered by this commit, since there's no way to propagate SIGSTOP to the new session that's created:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=37e4dc5ae842afa03849a47b123345906fdd81a2

commit 37e4dc5ae842afa03849a47b123345906fdd81a2
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2019-01-22 07:17:18 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2019-01-23 04:47:25 +0000

    pid-sandbox: pid-ns-init setsid support (bug 675870)
    
    Use setsid to isolate the parent process from signals sent
    to the process group, and forward signals to the entire
    process group with kill(0, signum).
    
    Bug: https://bugs.gentoo.org/675870
    Signed-off-by: Zac Medico <zmedico@gentoo.org>

 bin/pid-ns-init | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2020-01-02 08:41:43 UTC
(In reply to Zac Medico from comment #1)
> It's triggered by this commit, since there's no way to propagate SIGSTOP to
> the new session that's created:
> 
> https://gitweb.gentoo.org/proj/portage.git/commit/
> ?id=37e4dc5ae842afa03849a47b123345906fdd81a2

Ah yes. I found that code to be suspect, particularly because it mentions SIGSTOP. :)

The comments there had me confused as to which process the parent process is (emerge, the ebuild's phases, something else?).
Comment 3 Zac Medico gentoo-dev 2020-01-02 10:23:47 UTC
In that commit message, parent process refers to the emerge process.
Comment 4 Zac Medico gentoo-dev 2020-10-27 21:24:49 UTC
*** Bug 751493 has been marked as a duplicate of this bug. ***
Comment 5 Christopher Head 2020-10-28 01:29:24 UTC
The same applies to SIGTSTP, which means Ctrl+Z doesn’t properly suspend an emerge run.
Comment 6 Zac Medico gentoo-dev 2020-10-28 07:56:49 UTC
(In reply to Christopher Head from comment #5)
> The same applies to SIGTSTP, which means Ctrl+Z doesn’t properly suspend an
> emerge run.

We can fix it to forward SIGTSTP to the process group created by the setsid call.
Comment 8 Larry the Git Cow gentoo-dev 2020-11-01 21:46:15 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=8b7edb648814cc53774c5841e45d8cc325bcef6e

commit 8b7edb648814cc53774c5841e45d8cc325bcef6e
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2020-10-28 08:34:51 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2020-11-01 21:45:01 +0000

    pid-sandbox: Forward SIGTSTP and SIGCONT (bug 704498)
    
    For correct operation of Ctrl+Z, forward SIGTSTP and SIGCONT
    to all sandboxed pids.
    
    Fixes: 37e4dc5ae842 ("pid-sandbox: pid-ns-init setsid support (bug 675870)")
    Bug: https://bugs.gentoo.org/704498
    Signed-off-by: Zac Medico <zmedico@gentoo.org>

 bin/pid-ns-init | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)
Comment 9 Zac Medico gentoo-dev 2020-11-01 21:51:29 UTC
Since it's impossible to handle SIGSTOP, I suppose we can consider this fixed by the SIGTSTP handling.
Comment 10 Larry the Git Cow gentoo-dev 2020-11-02 02:01:29 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=43cc36f055d6c4fd9c8761ecb50f57027180a1dd

commit 43cc36f055d6c4fd9c8761ecb50f57027180a1dd
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2020-11-02 01:57:51 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2020-11-02 01:58:00 +0000

    sys-apps/portage: Bump to version 3.0.9
    
     #199722 Enable QA Notice for deprecated hasq/useq in *rm phases
     #704498 Fix pid-sandbox to handle Ctrl+Z correctly
     #752066 Add emerge --quickpkg-direct-root option
     #752147 Fix make.conf to expand special *ROOT variables
     #752153 Add @golang-rebuild package set
    
    Bug: https://bugs.gentoo.org/752168
    Bug: https://bugs.gentoo.org/199722
    Bug: https://bugs.gentoo.org/704498
    Bug: https://bugs.gentoo.org/752066
    Bug: https://bugs.gentoo.org/752147
    Bug: https://bugs.gentoo.org/752153
    Package-Manager: Portage-3.0.9, Repoman-3.0.2
    Signed-off-by: Zac Medico <zmedico@gentoo.org>

 sys-apps/portage/Manifest             |   1 +
 sys-apps/portage/portage-3.0.9.ebuild | 267 ++++++++++++++++++++++++++++++++++
 2 files changed, 268 insertions(+)
Comment 11 Christopher Head 2020-12-01 20:43:25 UTC
Are you sure this is fully fixed? I was using Portage 3.0.9 to build dev-lang/rust-1.47.0-r2. I pressed Ctrl+Z and got back to a shell, but there were still rustc processes running, using 100% CPU, much later. I do run with EMERGE_DEFAULT_OPTS="--jobs 4 --load-average 8" and MAKEOPTS="--jobs 4 --load-average 8" in case that makes a difference.
Comment 12 Zac Medico gentoo-dev 2020-12-02 00:58:13 UTC
(In reply to Christopher Head from comment #11)
> Are you sure this is fully fixed? I was using Portage 3.0.9 to build
> dev-lang/rust-1.47.0-r2. I pressed Ctrl+Z and got back to a shell, but there
> were still rustc processes running, using 100% CPU, much later. I do run
> with EMERGE_DEFAULT_OPTS="--jobs 4 --load-average 8" and MAKEOPTS="--jobs 4
> --load-average 8" in case that makes a difference.

I can see that the first pid-ns-init process does not enter the "stopped by job control signal" state, nor do any of the processes below it in the pid namespace.