Bugzilla – Bug 439438
yast2 retains lock on xkill termination
Last modified: 2008-10-29 15:49:29 UTC
When configuring the printer YaST2 started to hang(Bug 439431) and retained its lock on the package management system after being terminated by xkill. There should be a signal handler to free the lock on crashes, because this failure requires an annoying reboot. zypper ar ... ... A ZYpp transaction is already in progress. This means, there is another application using the libzypp library for package management running. All such applications must be closed before using this command.
Created attachment 248281 [details] crashed printer configuration involving package management
Besides revising the yast2 code for signal handlers to free package management locks the best solution for this specific issue would certainly be to let updates for printer driver files be prefetched by the regular update process. This will be especially important if the user works offline and plugs a new printer. In general I would suggest all additional packages for YaST-configurations to be preinstalled at Opensuse 11.1.
xkill (the KDE Ctrl-Alt-Esc "skull and cross-bones" mouse cursor) works fine for me with YaST2 (y2base) processes. But if a process hangs in a syscall that ignores signals like in that bug #439431, xkill is just not good enough: xkill just sends a SIGTERM (signal 15). That's more like a friendly hint that a process might please consider to voluntarily terminate. But that won't work in every scenario. In those cases, you need to send a SIGKILL (signal 9) which cannot be ignored. Use killall -9 y2base in those cases.
I mean, xkill has worked well, but Yast has terminated incorrectly retaining a lock on the package management system. The second issue is that Yast should best not need to access the package management system for installing a printer driver at all because this should work offline as well (prefetch new drivers via updates).
.
xkill did NOT work well. It obviously didn't kill the process holding the lock; that process was stuck in a non-interruptible syscall during hardware probing. See bug #439431. And for any other issues, please open a separate bug report. It's impossible to keep track of the status of several separate issues in one bug report.