Bugzilla – Bug 410627
zypper should exit gracefully after receiving TERM or INT signal
Last modified: 2014-01-13 09:14:26 UTC
I have tried the command "zypper update -t package kde4*". I have noticed that the corresponding protocol file "/var/log/zypper.log" grows very fast - several hundred MB in a few seconds. I doubt that this growth rate is acceptable. I have tried to abort this process. I got the reaction "OK OK! Exitting immediately..." for a command like "kill -TERM 7991" sometimes while I had to stop it by "kill -KILL" in other tries to prevent the disk allocation of some GB in a few minutes. It seems that there is a danger that the log partition might become full at an unexpected speed because of update approaches with wildcards in (package) names.
I have noticed that a double "Ctrl+C" results also in the message "OK OK! Exitting immediately...". It happened that the program did not always return. (The command "kill -KILL" or a similar action in the tool "ksysguard" was needed to stop it.) I would like to know under which circumstances an abort/cancel for a started update process is refused here.
*** This bug has been marked as a duplicate of bug 404715 ***
The issue "zypper.log is huge (9.5 GB)" is related. But I guess that unsafe responses to termination/cancel signals for update processes should be further checked.
Yes, zypper currently exits only if you send the TERM or INT signal twice (e.g. you hit ctrl+c twice). It is meant to quit gracefully after the first signal, and exit forcefully after the second. But the former case is not implemented yet, so currently you need to request the termination twice. There is no enhancement request covering this, so i'll keep this one.
Markus, can you pls provide info requested here https://bugzilla.novell.com/show_bug.cgi?id=404715#c1 ? The original reporter did not respond so far, you may have the needed info :O)
No, I'm sorry that I will not start a statistical analysis on so huge log files. (I deleted them after a short look.) I prefer to stop the update process and the "mad" logging before my "var" partition will become completely full. I do not know the maximum size for the log partition so far to store all generated data when the zypper tool "explodes" in the conflict/dependency resolution dimension. I would also appreciate ways to dramatically reduce the log detail level. I'll add a test case for problematic update candidates to the other issue. My issue "Cancel a long running dependency resolution try in package manager" (bug #404770) might be affected, too.
*** Bug 590290 has been marked as a duplicate of this bug. ***
still relevant in 11.4
It still happens, and One has to crtl+z because ctrl+c doesn't work, and later kill -9 PID, or crtl+c and bis. "(changed during the 2011-02-20 Open-Bugs-Day about bugs for obsolete versions of openSUSE)"
Please reopen and provide the zypper.log if you experience this with a newer zypper version (openSUSE 12.3 or later).