Summary: | Portage 2.1.9.42 traceback: os.kill, OSError: [Errno 1] Operation not permitted (hardened kernel) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Paweł Hajdan, Jr. (RETIRED) <phajdan.jr> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | hardened-kernel+disabled, zerochaos |
Priority: | Normal | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 484436 |
Description
Paweł Hajdan, Jr. (RETIRED)
2011-03-10 12:57:55 UTC
It seems that somebody sent either SIGINT or SIGTERM to that emerge process, since that's the only way to trigger line 151 of PollScheduler.py. It's really strange that kill() raised EPERM, since emerge should always have permission to send a kill signal to its subprocesses. (In reply to comment #1) > It seems that somebody sent either SIGINT or SIGTERM to that emerge process, > since that's the only way to trigger line 151 of PollScheduler.py. It's really > strange that kill() raised EPERM, since emerge should always have permission to > send a kill signal to its subprocesses. Right, I think I sent a few Ctrl-C's (bad idea) to the "hung" screen. Anyway, I guess the traceback is still unexpected. I'm not sure if this traceback is reproducible. I guess we can just wait and see if anyone else experiences it. It's mainly a cosmetic issue, since it can only happen after emerge has been interrupted by SIGINT or SIGTERM. Previous versions of portage simply exited immediately, but recent versions of portage-2.1.9.x try to do some minimal cleanup before exiting. That kill "Operation not permitted" error could be triggered by grsec combined with dropped privileges from the default FEATURES=userfetch setting. I recall somebody else having a similar issue with userpriv recently, and their dmesg output showed a complaint from grsec. (In reply to Zac Medico from comment #4) > That kill "Operation not permitted" error could be triggered by grsec > combined with dropped privileges from the default FEATURES=userfetch > setting. I recall somebody else having a similar issue with userpriv > recently, and their dmesg output showed a complaint from grsec. I'm on hardened, running userfetch, userpriv, usersync, usersandbox and I can reproduce this trivially (happens to me all the time but at random intervals). If anyone has ideas, I'll be happy to test whatever you like with ~1 day testing. Most days this happens to my build system 5-10 times. Kill normally does not thow an EPERM error like this, so it seems like a possible bug in the hardened kernel. Handle EPERM from os.kill(): http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2cd7f834919be0d9549bbe5d8f712e03ce95d5eb If you want to use that patch with FEATURES=cgroup, you also need this: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a5641bf514ded96c160e6cb94a1fdf9ede84778a This is fixed in 2.2.2. |