[opensuse-factory] Update killed user session (was: New Tumbleweed snapshot 20160223 released!)
This is the first time in years that an update killed my running session. Does anybody know what triggered this (I suspect the xdm package) and if this was really necessary? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Achim Gratz <Stromeko@nexgo.de> [02-25-16 14:00]:
This is the first time in years that an update killed my running session. Does anybody know what triggered this (I suspect the xdm package) and if this was really necessary?
I had it happen on two systems and not on three others ??? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 25, 2016 at 07:59:30PM +0100, Achim Gratz wrote:
This is the first time in years that an update killed my running session. Does anybody know what triggered this (I suspect the xdm package) and if this was really necessary?
It was caused by the updated xdm. Please consider to file a feature request to start zypper inside of a screen session. Then at least the update continues and we lower the risk of a broken system. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Lars Müller writes:
It was caused by the updated xdm.
Thanks for the confirmation.
Please consider to file a feature request to start zypper inside of a screen session. Then at least the update continues and we lower the risk of a broken system.
I was updating with the update applet from KDE. Somehow zypper is involved, but a screen session wouldn't have helped I think. The update was complete and had no failure, btw. I just wasn't prepared for the session to be killed (after it refused to close itself). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 25, 2016 at 08:54:45PM +0100, Achim Gratz wrote:
Lars Müller writes:
It was caused by the updated xdm.
Thanks for the confirmation.
Please consider to file a feature request to start zypper inside of a screen session. Then at least the update continues and we lower the risk of a broken system.
I was updating with the update applet from KDE. Somehow zypper is involved, but a screen session wouldn't have helped I think. The update was complete and had no failure, btw. I just wasn't prepared for the session to be killed (after it refused to close itself).
Lars' idea wasn't meant to prevent session being shut down during the update (which I also see as absolutely unacceptable) but only to make sure zypper itself is not killed with the X session, possibly leaving the system in random inconsistent state. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Kubecek writes:
Lars' idea wasn't meant to prevent session being shut down during the update (which I also see as absolutely unacceptable) but only to make sure zypper itself is not killed with the X session, possibly leaving the system in random inconsistent state.
I'm not sure what goes on behind the scenes of the updater applet, I think it's not calling into zypper directly, but using libzypp. Anyway, I usually do direct zypper updates from one of the vtx, not the X session, for exactly that reason (it's a bit cumbersome to review the output later in those terminals, but that's a different story). In any case, updates that are about to kill something that is vital to the user should announce themselves and probably not start at all when run from a GUI applet. I'd file a bug if the xdm update should not have had that result, otherwise I am back to asking why this was deemed necessary. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 25, 2016 at 09:34:32PM +0100, Achim Gratz wrote:
Michal Kubecek writes:
Lars' idea wasn't meant to prevent session being shut down during the update (which I also see as absolutely unacceptable) but only to make sure zypper itself is not killed with the X session, possibly leaving the system in random inconsistent state.
I'm not sure what goes on behind the scenes of the updater applet, I think it's not calling into zypper directly, but using libzypp.
Anyway, I usually do direct zypper updates from one of the vtx, not the X session, for exactly that reason (it's a bit cumbersome to review the output later in those terminals, but that's a different story).
In any case, updates that are about to kill something that is vital to the user should announce themselves and probably not start at all when run from a GUI applet. I'd file a bug if the xdm update should not have had that result, otherwise I am back to asking why this was deemed necessary.
You unfortunately still missed to mention the bug ID. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Lars Müller writes:
You unfortunately still missed to mention the bug ID.
I still don't have the slightest idea which component to file the bug against. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
26.02.2016 22:13, Achim Gratz пишет:
Lars Müller writes:
You unfortunately still missed to mention the bug ID.
I still don't have the slightest idea which component to file the bug against.
This one? http://bugzilla.opensuse.org/show_bug.cgi?id=968405 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Achim Gratz writes:
Lars Müller writes:
You unfortunately still missed to mention the bug ID.
I still don't have the slightest idea which component to file the bug against.
A bit of trawling through the bugtracker reveals it's been filed already at https://bugzilla.suse.com/show_bug.cgi?id=968405 (and as I suspected it has already changed hands a few times). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 26, 2016 at 08:19:33PM +0100, Achim Gratz wrote:
Achim Gratz writes:
Lars Müller writes:
You unfortunately still missed to mention the bug ID.
I still don't have the slightest idea which component to file the bug against.
A bit of trawling through the bugtracker reveals it's been filed already at https://bugzilla.suse.com/show_bug.cgi?id=968405 (and as I suspected it has already changed hands a few times).
That's the bug causing the seen issue. Running zypper automatically inside screen would add an additional level of protection. And that's a new feature which has to be requested against openSUSE Tumbleweed and component libzypp. This is a feature/ enhancement. Please file a bug and report the ID back to this thread. Also add to the bug report a link to this thread in the openSUSE list archive. Cheers, Larts -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-02-27 17:39, Lars Müller wrote:
Running zypper automatically inside screen would add an additional level of protection. And that's a new feature which has to be requested against openSUSE Tumbleweed and component libzypp.
But the OP did not use zypper. He used the desktop update applet. The issue would be avoiding the desktop to crash, but perhaps postpone the actual update till an automatic graphic system restart. A new update paradigm. :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbR1wUACgkQja8UbcUWM1zcgAEAhnnJNVA4PgasELPxkDIl4X5J Mm4FhzugIXE0WjnL+5wA/jBMv3ITbiOG3Mb/QwhIcCYZ08Jhot9kqvYqFMM0UO3X =Mgea -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
27.02.2016 20:04, Carlos E. R. пишет:
On 2016-02-27 17:39, Lars Müller wrote:
Running zypper automatically inside screen would add an additional level of protection. And that's a new feature which has to be requested against openSUSE Tumbleweed and component libzypp.
But the OP did not use zypper. He used the desktop update applet. The issue would be avoiding the desktop to crash, but perhaps postpone the actual update till an automatic graphic system restart. A new update paradigm. :-)
The actual update happens in background, performed by packagekit daemon. At least I just had experienced the same and although I was kicked out of GUI session, the installation seems to continue. I could not find how can I query packagekit backend for current operations, at least before disk activity stopped :) So it appears to provide the same level of protection as zypper in screen. Except when packagekit itself is restarted :p
On Sat, Feb 27, 2016 at 08:11:00PM +0300, Andrei Borzenkov wrote: [ 8< ]
The actual update happens in background, performed by packagekit daemon. At least I just had experienced the same and although I was kicked out of GUI session, the installation seems to continue. I could not find how can I query packagekit backend for current operations, at least before disk activity stopped :)
pkmon Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-02-27 18:11, Andrei Borzenkov wrote:
27.02.2016 20:04, Carlos E. R. пишет:
On 2016-02-27 17:39, Lars Müller wrote:
But the OP did not use zypper. He used the desktop update applet. The issue would be avoiding the desktop to crash, but perhaps postpone the actual update till an automatic graphic system restart. A new update paradigm. :-)
The actual update happens in background, performed by packagekit daemon. At least I just had experienced the same and although I was kicked out of GUI session, the installation seems to continue. I could not find how can I query packagekit backend for current operations, at least before disk activity stopped :)
So it appears to provide the same level of protection as zypper in screen. Except when packagekit itself is restarted :p
Yes, in that sense, yes. But the user experiences a crash of his session. My suggestion is to get everything ready, tell the user to accept a session restart, close the session, update critical things, start the session again. Automatically. Windows does it this way, yes. Just saying an idea, I like how it is currently :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlbR5IcACgkQja8UbcUWM1y5XwD/Y9M2L85oqGqMz8IFQevAcKjl 31dWmHDe1MQmU79OA5cA/jhXcCYZVn4ntM0YuK/t4bWfPy59UtGGjaOXx32xiHkr =wubR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
27.02.2016 21:01, Carlos E. R. пишет:
On 2016-02-27 18:11, Andrei Borzenkov wrote:
27.02.2016 20:04, Carlos E. R. пишет:
On 2016-02-27 17:39, Lars Müller wrote:
But the OP did not use zypper. He used the desktop update applet. The issue would be avoiding the desktop to crash, but perhaps postpone the actual update till an automatic graphic system restart. A new update paradigm. :-)
The actual update happens in background, performed by packagekit daemon. At least I just had experienced the same and although I was kicked out of GUI session, the installation seems to continue. I could not find how can I query packagekit backend for current operations, at least before disk activity stopped :)
So it appears to provide the same level of protection as zypper in screen. Except when packagekit itself is restarted :p
Yes, in that sense, yes. But the user experiences a crash of his session. My suggestion is to get everything ready, tell the user to accept a session restart, close the session, update critical things, start the session again. Automatically. Windows does it this way, yes.
Windows does not close session - it reboots and installs updates during reboot. That is how packagekit offline updates work and I believe offline updates are the only ones supported by native GNOME client (I may be mistaken, but I got this impression when I looked last time).
Just saying an idea, I like how it is currently :-)
On 2016-02-27 19:09, Andrei Borzenkov wrote:
27.02.2016 21:01, Carlos E. R. пишет:
Yes, in that sense, yes. But the user experiences a crash of his session. My suggestion is to get everything ready, tell the user to accept a session restart, close the session, update critical things, start the session again. Automatically. Windows does it this way, yes.
Windows does not close session - it reboots and installs updates during reboot.
Correct. W10 seems to wait till you halt the computer, and then does the updates, sometimes taking ages, just when might be in a hurry. It is not an option. Some updates before halting, some before booting. But we could separate those updates that need a session restart and those that need a reboot, and those that just need a service restart or application restart.
That is how packagekit offline updates work and I believe offline updates are the only ones supported by native GNOME client (I may be mistaken, but I got this impression when I looked last time).
I don't know, I never use that tool. If it does that, cool.
Just saying an idea, I like how it is currently :-)
-- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, Feb 27, 2016 at 06:04:05PM +0100, Carlos E. R. wrote:
On 2016-02-27 17:39, Lars Müller wrote:
Running zypper automatically inside screen would add an additional level of protection. And that's a new feature which has to be requested against openSUSE Tumbleweed and component libzypp.
But the OP did not use zypper. He used the desktop update applet.
Any desktop applet utilizes PackageKit and that makes in SUSE based products use of libzypp. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 2016-02-25 19:59, Achim Gratz wrote:
This is the first time in years that an update killed my running session. Does anybody know what triggered this (I suspect the xdm package) and if this was really necessary?
Well, this has been known for years. I recommended running this type of updates (factory aka tumbleweed) on text mode. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (6)
-
Achim Gratz -
Andrei Borzenkov -
Carlos E. R. -
Lars Müller -
Michal Kubecek -
Patrick Shanahan