Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 21509 - [IDEA] Ability to cleanly stop emerging multiple packages after the current jobs complete.
Summary: [IDEA] Ability to cleanly stop emerging multiple packages after the current j...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 853214 (view as bug list)
Depends on:
Blocks: 184128 472746
  Show dependency tree
 
Reported: 2003-05-22 18:12 UTC by J.C. Wren
Modified: 2023-08-01 06:34 UTC (History)
7 users (show)

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


Attachments
allow the current ebuild to complete before exiting on SIGINT (interrupt.patch,2.21 KB, patch)
2007-03-31 12:10 UTC, Zac Medico
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description J.C. Wren 2003-05-22 18:12:28 UTC
Suppose one does an 'emerge -Up world', and there are 35 packages to upgrade. 
It would be nice to able to say something to the effect of 'emerge --stopworld',
which would cause the running emerge to terminate once it finishes the current
ebuild.  

Reproducible: Always
Steps to Reproduce:
Comment 1 Alec Warner (RETIRED) archtester gentoo-dev Security 2005-07-30 13:18:56 UTC
Quoting Jason: "Putting a hold on feature requests for portage as they are 
drowning out the bugs. Most of these features should be available in the next 
major version of portage. But for the time being, they are just drowning out the 
major bugs and delaying the next version's progress. 
 
Any bugs that contain patches and any bugs for etc-update or dispatch-conf can 
be reopened. Sorry, I'm just not good enough with bugzilla. ;)"

This will not be fixed in stable, but should be fixed in the next major release.

If you need to suspend a merge, you can always use control+z ( job control 
suspend ) on your shell as a temporary workaround, although it is a cheap hack 
that doesn't cover all situations :)
Comment 2 Marius Mauch (RETIRED) gentoo-dev 2007-01-11 12:09:58 UTC
Reopenin for consideration.
Comment 3 Zac Medico gentoo-dev 2007-01-11 19:02:46 UTC
I think this would be best implemented as a job control system that allows one or more of any number of jobs to be cancelled, paused, or restarted.  This would be related to the emerge daemon idea discussed in bug #147516.
Comment 4 Steve L 2007-03-30 23:30:21 UTC
(In reply to comment #3)
> I think this would be best implemented as a job control system that allows one
> or more of any number of jobs to be cancelled, paused, or restarted.  This
> would be related to the emerge daemon idea discussed in bug #147516.
> 
Well it would be a lot simpler to change the CTRL-C handling imo. I was going to do this for my script[1] but it's hard to get the interaction with subshells so I left it for later. Seems like something portage could handle a lot more easily?

1. http://forums.gentoo.org/viewtopic-t-546828.html
Comment 5 Zac Medico gentoo-dev 2007-03-31 01:20:20 UTC
(In reply to comment #4)
> Well it would be a lot simpler to change the CTRL-C handling imo.

I think that lots of users would be annoyed if CTRL-C did anything other than what it does now.  It would be more appropriate to use a signal other than SIGINT, such as SIGUSR1 or SIGUSR2. 
Comment 6 Zac Medico gentoo-dev 2007-03-31 03:43:07 UTC
(In reply to comment #5)
> I think that lots of users would be annoyed if CTRL-C did anything other than
> what it does now.

I'm told that some programs such as vlc modify their behavior depending on the number of signals received.  The first SIGINT would show a message allow the current build to complete while the second SIGINT would force immediate exit.  That seems like a pretty good solution.
Comment 7 Steve L 2007-03-31 09:21:23 UTC
Yeah to me too :D
Comment 8 Zac Medico gentoo-dev 2007-03-31 12:10:40 UTC
Created attachment 115026 [details, diff]
allow the current ebuild to complete before exiting on SIGINT

This patch works but if you sent the signal via CTRL-C then it will kill the ebuild process and I don't see a way to block the signal from reaching nested processes like that.  You have to send the signal to the pid another way such as by running `pkill emerge` in a separate terminal.
Comment 9 Steve L 2007-03-31 21:39:14 UTC
Ah ok, same problem i had, thought it was easier from within portage, my bad. The pkill is at least an implementation for the user, thanks for response and work.
Comment 10 Steve L 2007-04-02 22:16:30 UTC
Since CTRL-C is tricky, why not go with your idea of SIGUSR1? A simple pkill -USR emerge could be aliased as stopemerge or something, and scripts could easily use pkill with -s 0 or even -f.
Looking at that patch you'd need to add a different signal handler (or extend the existing one) but it would be simpler and, as you pointed out, more consistent.
Comment 11 J.C. Wren 2007-04-02 22:55:28 UTC
Personally, I'd prefer "emerge stop"

--jc
Comment 12 Steve L 2007-07-12 02:23:13 UTC
(In reply to comment #11)
> Personally, I'd prefer "emerge stop"

Yeah I'm sure you would, but it'd only be an alias to pkill. IOW not something to ask the portage devs about.
Comment 13 Steve L 2007-07-25 19:32:24 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Personally, I'd prefer "emerge stop"
> 
> Yeah I'm sure you would, but it'd only be an alias to pkill. IOW not something
> to ask the portage devs about.
> 
Er sorry about that; I think I was in a bad mood at the time. It would only require the signal being sent to the running emerge, but a command for emerge, which would indeed be the best solution, would need portage devs to work on it.
Comment 14 Toralf Förster gentoo-dev 2021-07-14 16:30:37 UTC
a simple magic "STOP" file should be enough - no signal handling needed IMO.
emerge just acts on the the existence of that file.
Comment 15 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-06-21 01:29:10 UTC
*** Bug 853214 has been marked as a duplicate of this bug. ***