Summary: | wishlist! portage suspend, resume jobs | ||
---|---|---|---|
Product: | Portage Development | Reporter: | dan <overvolting> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED CANTFIX | ||
Severity: | enhancement | CC: | radek |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
dan
2003-02-28 18:07:08 UTC
You should already have the ability to do this. It's not in portage but built into bash (and other shells I'm sure). It's called Job Control. Type: man bash /JOB CONTROL (to search for job control in the man page) A simple summary: Start your program ('emerge -uD world' for example) When you need to suspend (pause) hit 'ctrl-z'. You should get something like "[1]+ Stopped emerge -uD world" and a prompt. Use computer as needed. When you want to resume run the command 'fg' I agree with Tyler, theres no need to spend time reinventing the wheel as it were. In addtion to the CTRL-Z option, should you CTRL-C (or KILL) the emerge process, you can still use emerge --resume to start re-merging at the last package it was working on (only works if you haven't run another emerge command between them) Neither of the above comments solve the problem the original bug mentions in all cases. The job control solution won't survive a reboot. The emerge --resume won't preserve all the CPU time already invested in emerging a package. What would be nice is to be able to send emerge a signal (say USR1) which causes it to send HUPs/KILLs to compiles, or, cleanly finish patching/merging/whatever it is doing that you *don't* want to stop in the middle of, then die. It could also potentially write some tracking information to a file to be used when the resume begins (ie, unpack completed, patch completed, partway through compile). emerge --resume could then pick up that unpack, patch are completed, and simply kick off make again. I can't see any reasonable way to do this generically. Simply restarting src_compile is not an option. Adding a src_resume is not enough either - some sort of src_pause would be necessary. Although, that's not really doable either because src_compile is already doing its thing. Signal handling from within ebuilds? I don't think so. The only other way I can think of would be to write a virtual machine for compiling in. Not really doable either... |