Here are three small patches that fixes various issues in exiting / signal handling. This are all minor bugs, that have really bad effects, but it can't hurt to fix them... Patches are against 2.0.50_pre12. Reproducible: Always Steps to Reproduce:
Created attachment 23674 [details, diff] ebuild.sh--tee_log.fix This one fixes two small problems with the way recursion for per-ebuild logging is done: - first, the code seems to assume that $? will be the status of the recursive call (and then delete the success file if non-zero), but it is in fact the status of the last pipe command, "tee...", which always return 0. It has no wrong effect tho because it never happens that there is a success file whereas the exit status of the recursive call is non-zero. - second, when you don't use per-ebuild logging and Ctrl-C a build process, you get something like this: < snip some make commands > Caught signal 2 make[2]: *** Deleting file `date_parser.o' make[2]: *** Deleting file `context_menus.o' make[2]: *** [date_parser.o] Interrupt make[2]: *** [context_menus.o] Interrupt make[1]: *** [all-recursive] Interrupt make: *** [all] Interrupt /usr/portage/app-pda/gtkpod/gtkpod-0.60.ebuild: src_compile aborted; exiting. root % But with per-ebuild logging, you miss this messages, because the '| tee ...' dies too fast. I've added a SIGINT/SIGQUIT handler to the '| tee' process so that it don't die on user interrupt, but only once the recursive call has really exited.
Created attachment 23675 [details, diff] portage.py--wait_for_childs.patch Again with the previous "Ctrl-C during build" test, you will sometimes get this output: < snip some make commands > Caught signal 2 make[2]: *** Deleting file `date_parser.o' make[2]: *** Deleting file `context_menus.o' make[2]: *** [date_parser.o] Interrupt root % make[2]: *** [context_menus.o] Interrupt make[1]: *** [all-recursive] Interrupt make: *** [all] Interrupt /usr/portage/app-pda/gtkpod/gtkpod-0.60.ebuild: src_compile aborted; exiting. The "root %" prompt lost before the end of messages is here because emerge, the foreground process, exits before the spawned ebuild.sh. I think this is not a good thing: if a spawned process refuses to die on SIGINT for instance, the user won't notice it and will probably keep this process lost in the background. This patch makes portage exit function to wait for child process if any, thus solves this.
Created attachment 23676 [details, diff] emerge--atexit.patch I think there is a missunderstanding of "atexit" in emerge code: registering a function adds it to the stack of functions to execute on exit, but does _not_ remove the previously registered function as it is written in comments (or maybe this was true in some previous python versions?). Like it is now, when emerge exits, portageexit() is called twice: once because it is registered, and once by emergeexit(). And when an emerge is cancelled by a SIGINT, emergeexit() is called twice because of the SIGINT handler code (this one, you can see it in emerge.log: the "Terminating" message is duplicated), and thus portageexit() three times. The patch removes manual calls to portageexit().
In comment #O, I've wrote: > This are all minor bugs, that have really bad effects It must read: This are all minor bugs, that have _no_ really bad effects :)
Created attachment 24031 [details, diff] ebuild.sh--log-fixes.patch For the "tee dies too fast on Ctrl-C" problem, there is in fact an option that does exactly what was needed :) So here is a version of the patch without the SIGINT trap, but with a "-i" instead. Much simpler.
Created attachment 24233 [details, diff] portage.py--wait-for-children.patch Sorry, the previous patch was not diffed against a vanilla portage. This one is, and should apply correctly on 2.0.50_pre19.
Created attachment 24894 [details, diff] emerge--atexit.patch I've also noticed that there are some other "*** terminating" messages in emerge.log that doesn't correspond to any "Starting emrge...". They come from --pretend mode. Since there are no other log message in this mode, i've added to this patch a test to remove also this one.
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
