Summary: | Ctrl-Z does not interrupt the build correctly (child processes are not frozen/suspended) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | j.habenicht |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | arsen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 910332 |
Description
j.habenicht
2023-09-02 09:49:47 UTC
There is something weird going on with parallelization on mozilla products, but did it just finish the one heavy process and stop after perhaps? So it didn't start new processes, but finished the active ones? Hey Joonas, thanks for asking The process list shows only one process (emerge world, pid 8894) in stopped state. All the other processes are allowed to continue. So it seems, the emerge process does not propagate the signal to its child processes. But yes, you are right. I only tested Ctrl-Z twice and looked about 10 seconds to the result. I did not check, if the make process stopped spawning new processes. Judging from the process state I'd say it does spawn new processes. Just a minor note: In previous build systems consisting of ebuild, configure, make and gcc typing Ctrl-z has been enough to stop the entire build immediately. With all (sub-)processes waiting in stopped state (T). I thought this should be the same over here? all the best I don't think this is Mozilla specific, I can reproduce it with e.g. Emacs. *** This bug has been marked as a duplicate of bug 704498 *** |