Bug 307364

Then it looks like you took the wrong approach to kill that program.

Beware, though, that killing an ongoing package installation might leave your system in a very undefined state, depending on exactly what the back-end (libzypp and/or the "rpm" command) is currently doing.

For example, if a package gets updated (which is the usual operation when installing patches), first the pre-uninstall script is executed, then the files of the old package version are collected and deleted, then the post-uninstall script is executed, then the new package's pre-install script is executed, the new package's files are copied from the "cpio" archive (an rpm package is little more than a cpio archive with additional headers), then the post-install script is executed.

If you kill that process with brute force (e.g., with a SIGKILL (Signal #9)), you will end up with a half-installed package. The old files might already be gone, but the new ones not properly installed yet. Or they may be installed, but the post-install script may not be executed yet (which might take care of copying previous config file variables to the new config file).

You might get lucky with that. But then, you might not.

Patches are even more critical. A patch is normally considered a "transaction", i.e., a set of operations that has to be performed consistently and completely or not at all.

For example, a patch to the update stack typically contains a new libzypp, new yast2-pkg-bindings, new yast2-perl-bindings, new yast2-qt, new yast2-ncurses. If you install only one of those packages, the versions will not match, and the update stack will be broken.

This is why normal signals are caught while packages and/or patches are being installed or updated. This is (95% sure) also what you saw as an error message.

If you simply used your desktop's menu to shut down the machine, it will attempt to communicate this with all running desktop applications, of which of course the Qt package selector is one. The desktop will send a session management event: "Desktop session is about to end, save your status and quit yourself". But while packages are being installed, this request cannot be fulfilled.

It depends on the desktop (KDE? GNOME?) what happens next. If that session management request is not answered, typically a SIGTERM is sent next - another signal that applications can catch. After a couple of seconds, a SIGKILL is sent (at the latest when the system shuts down). This is something an application cannot catch. It will instantly be killed.

If I understand you correctly, you pressed your machine's "power off" button. Is that correct?

AFAIK that "power off" button is translated into DBUS events that ultimately are sent to the desktop that in turn translate this event into a "session end" event like described above.

Which desktop are you using?
Did the system finally shut down (despite the complaint) or not?


One way or the other, "power off" is NOT the method of choice if something goes wrong on a Linux system. MS Windows users got used to rebooting if anything looks suspicious, but this is a bad approach for a Linux system.

On Linux, you can get control of applications that do something you don't want in various ways:

On the command line, use the "kill" command with the process ID (PID) and a signal number. If you don't know the PID (which is the normal case), you can find it out with the "ps" command. Alternatively, you can use the "killall" command which kills all processes with a given name:

    killall -9 y2base

sends a signal #9 (SIGKILL) to all "y2base" processes (y2base is the YaST2 binary).

On KDE, there is also "ksysguard" that does the same as "ps" and "kill" with a nice GUI.

KDE also has the "kill cursor": Press Ctrl-Alt-Esc, and the mouse cursor turns into a skull and crossed bones. The application you click on with that cursor will die a SIGKILL death.


BTW since YaST2 is running as "root" (with superuser privileges), you need root privileges to kill it, of course. So in the case of YaST2, you have to use something like

    sudo killall -9 y2base

which ultimately is also the reason why a desktop session running as non-root cannot simply kill a running YaST2 process.

Did you try to terminate it with "root" privileges?

BTW this was installing patches or packages in the installed system, not a new system installation, right?

Stefan, thank you very much for such explanation. I'll try to answer your questions step by step, but maybe at first once again the situation.

I was surprised by ETA the SM gave me -- during installation SM is not responding to user action (try "abort") so I was hoping I press power off (it is soft power off button, not power cut off like in older desktop) and SM will notice it and just install the current package and leave the rest.

It didn't happen. You know, when the software is not responding, what can you do?

Btw. it would be really nice to see some emergency abort feature (skip the current and the rest) and emergency rollback (skip current + rest, but rollback all installed in current session).

> AFAIK that "power off" button is translated into DBUS events that ultimately
> are sent to the desktop that in turn translate this event into a "session end"
> event like described above.

AFAIK -- yes.

> Which desktop are you using?

KDE.

> Did the system finally shut down (despite the complaint) or not?

Well, after I killed all yast (killall ...) from root, yes, I was able to shut it down.

> One way or the other, "power off" is NOT the method of choice if something goes
> wrong on a Linux system. 

I am not taking about unplugging it, power off button is a normal and convenient way to shutdown the system. It works exactly the same if I press ctrl+alt+del and choose "shutdown".

And about going wrong -- what choice did I have, if I am missing something please let me know (waiting ~12 hours is not acceptable for me).

> KDE also has the "kill cursor": 

THANK YOU!

> Did you try to terminate it with "root" privileges?

Sure it worked. But it is a brute force method of interruption. Program does not have chance (ok, it has a bit, it could intercept this signal, but it is really low level). Note, that it is more useful to get signal in Qt level about power-off button press and manage aborting program in GUI mode -- in nice, user-friendly manner.

PS. I was installing and upgrading some packages.

So this is really about the "Abort" button not being responsive enough.
-> bug #299536

*** This bug has been marked as a duplicate of bug 299536 ***

(In reply to comment #4 from Maciej Pilichowski)
> Btw. it would be really nice to see some emergency abort feature (skip the
> current and the rest) and emergency rollback (skip current + rest, but 
> rollback all installed in current session).

I am afraid rollback is very much out of reach (albeit often requested to uninstall patches, for example): There is no reliable way to undo whatever any of those pre-install or post-install (or pre-uninstall / post-uninstall) scripts did. This is a problem of how RPM works in principle.



> > One way or the other, "power off" is NOT the method of choice if something 
> > goes wrong on a Linux system. 
> 
> I am not taking about unplugging it, power off button is a normal and
> convenient way to shutdown the system. It works exactly the same if I press
> ctrl+alt+del and choose "shutdown".

Right. Which is yet another not-method-of-choice to fix problems under Linux. ;-)

 
> And about going wrong -- what choice did I have, if I am missing something
> please let me know (waiting ~12 hours is not acceptable for me).

The time estimate is just that: An estimate. If your connection is very slow but then becomes quicker after a while, the initial estimate may be way off. There is no real way to predict how long a package download and installation will take, yet it was requested so often that we were forced to implement something that really is completely bogus: We wait for a while (1 min) and watch the data transfer rate during this time and then extrapolate that to the remaining packages. This of course assumes that the transfer rate will remain the same, which may or may not be the case.

I posted another report, so I proposed there a nice method to make rollback available for installation. It is more a trick, but it should work perfectly (from user point of view).

> > ctrl+alt+del and choose "shutdown".
> Right. Which is yet another not-method-of-choice to fix problems under Linux.
> ;-)

:-))) Stefan, do you ever turn off your computer? :-)) If yes, please, don't tell me you type each time as root
shutdown -h -t 1 now

I wanted to turn off my computer! This was the reason I wanted to abort the SM, not vice versa!

> > And about going wrong -- what choice did I have, if I am missing something
> > please let me know (waiting ~12 hours is not acceptable for me).
> The time estimate is just that: An estimate. If your connection is very slow
> but then becomes quicker after a while, the initial estimate may be way off.

After an 15 minutes and with >700MB to download knowing your top download speed you can do the math, and not even get ETA but the best time you achieve. So I was not panicking, it was sane decision -- I cannot wait that long, I have to turn off computer.

Btw. I don't see it is a duplicate of the report you mentioned, yes it is true, it would be nice to handle "abort" button but displaying some popup window "qt blocked something" on power off is not user-friendly in any way (and does not tell anything, ask users what is "qt" :-) ).
At least there should be popup windows saying "power off during installation is not possible", or something like this. 

The other report discuss useful, but only superficially related feature.


Please, reopen this report on its own (I am not doing this because I don't want to force any decision here) -- thank you in advance.
There is one obstacle in the way -- not willing to cooperate SM :-)