Mailinglist Archive: opensuse-bugs (15061 mails)
| < Previous | Next > |
[Bug 307364] power off is blocked by yast (software manager)
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Wed, 5 Sep 2007 03:35:06 -0600 (MDT)
- Message-id: <20070905093506.622C0245350@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=307364#c1
Stefan Hundhammer <sh@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sh@xxxxxxxxxx
--- Comment #1 from Stefan Hundhammer <sh@xxxxxxxxxx> 2007-09-05 03:35:05 MST ---
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.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Stefan Hundhammer <sh@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sh@xxxxxxxxxx
--- Comment #1 from Stefan Hundhammer <sh@xxxxxxxxxx> 2007-09-05 03:35:05 MST ---
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.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
| < Previous | Next > |