KDE shutdown "abort active sessions" prompt should before logout is done

[Alan Jenkins]

Binary package hint: kdebase

Kubuntu 8.10, fully updated
kdebase-bin 4:4.1.3-0ubuntu1~intrepid1

If I have an active console session when I shutdown, KDE4 asks me to confirm that I want to abort them.

However, it does this at the login screen, *after* closing my desktop session. The behaviour I recall of KDE3 is that I get prompted *before* my desktop session is closed. I think the old behaviour makes more sense. It seems more forgiving anyway.

I guess it was just easier to implement this way, but pretty please can I have the old behaviour back?

Thanks!

[Harald Sitter (apachelogger)]

Hello.

I actually don't recall it doing this in the desktop session in KDE 3. Anyway. Could please line out a rationale why it would make more sense to do this before the desktop session closes? The main purpose of this feature is to prevent unwanted shutdown of remote sessions as far as I know. In any case I fail to see the relation between a console session and the desktop session.
Some enlightment please :)

Have a nice day.

[Alan Jenkins (aj504)]

Console sessions are a bit of a red herring. I first saw this feature when using user switching. I've seen Vista do something similar (don't ask me the details).

You're right, KDE3 does exactly the same thing. So this is a feature request, not a regression, sorry about that.

Here's one point: It takes several seconds to log out. This is especially true when running Thunderbird, which takes a few seconds to shut down itself. I think it probably suffers from using fsync() on ext3.

So if you click "turn off", you may wait long enough to see any "unsaved changes" dialogues, but not long enough to see the "other open sessions" dialogue. You could walk away and unintentionally leave your computer in limbo. It would be more user friendly if all obstacles to turning off could be presented at the same time.

[Harald Sitter (apachelogger)]

Thank you very much for the information.
I guess it would indeed make sense to streamline this. Maybe a timeout for the session dialog would be already enough?

In any case this workflow flaw also needs to be reported to KDE (http://bugs.kde.org), in fact, it probably would be best if the KDM maintainer decides how to solve this problem.

Alan, if you have time it would be very nice if you could post an accompanying bug report in KDE's bug tracker and file it's URL here. Otherwise someone of the team will do this, at some point... hopefully :)

Thank you so far.

[Vdboor-f (vdboor-f)]

Version: onbekend (using 4.2.00 (KDE 4.2.0) "release 83.1", KDE:KDE4:Factory:Desktop / openSUSE_11.0)
Compiler: gcc
OS: Linux (i686) release 2.6.25.20-0.1-default

I think KDM shows the confirmation dialog for "close active sessions" a bit too late. Example case:
 - I hit the "Shutdown computer" option from the logout menu.
 - I leave my computer.
 - ...
 - KDM interrupts the shutdown, prompting that I have an active session at tty1.

Either I find my computer still on next morning, or I have to patiently wait for KDE to exit, and see if KDM still has something to tell me.

I'd prefer if the confirmation dialog could be shown directly after pressing "shutdown computer". This way I can trust my computer to shutdown when I say so, instead of having to check it myself each time.

[Absorbb (absorbb)]

I think this is very important feature. And current behavior may threated as bug.
kde try much time to logout with black screen shown - so i often leave my computer and go sleep to another room. and then pc works all night.

And there are situations when i don't want to leave my session if i see that other session active.

And i think in kde4 must be possibility to instantly turn to another active kde session without logout to kdm screen. As i remember this feature was in kde3.

[Oswald Buddenhagen (ossi-kde)]

to whomever wants to implement that: libkworkspace has KDisplayManager::localSessions(). this needs to be forked into activeSessions() and used accordingly.
not to forget: the permission check. and what about authentication? as is, kdm will ask once the session has ended (which is about the same as this report).
this is in fact closely related to bug 59353 and bug 89023.
the gnomers are working on an integrated solution with ConsoleKit and PolicyKit. i guess we should use that once it hits the distros.

[Absorbb (absorbb)]

Please! Fix this before 4.3 release.
You already show pretty dialog with all current active sessions after pressing "Switch user"
What it worth to you to show warning dialog just after i press "Shutdown" or "Restart" when you already know about all opened sessions. You can simply show almost the same dialog as in "Switch user" case with only change "Shutdown" button instead of "Start new session"

[David Nemeskey (nemeskeyd)]

I also propose a timeout on the dialog. So if the user doesn't press any
buttons in, say 30 seconds or 1 minute, the system should assume that he went
to work/bed, and just continue with the shutdown.

[David Nemeskey (nemeskeyd)]

Same bug in KDE tracker: https://bugs.kde.org/show_bug.cgi?id=183274

[Alan Jenkins (aj504)]

Thanks! I'm not sure about the timeout idea.

If you run a shutdown on your own session, you get a last chance to save changes in session-aware apps, right? My concern is that the other sessions won't get that chance. I don't know exactly what would happen, but I suspect it would cause work to be lost in some circumstances.

[Nemeskey-david (nemeskey-david)]

From a comment in #200444:
"fwiw, the "Even when logged off from the tty console" issue is an upstart bug
(see downstream report https://bugzilla.redhat.com/show_bug.cgi?id=470004 )"

[Nemeskey-david (nemeskey-david)]

Confirmed in Ubuntu Jaunty, KDE 4.3.0.

I completely agree with the suggestions thus far. However, I think it would also help to put a timeout on the dialog. So if the user doesn't press any buttons in, say 30 seconds or 1 minute, the system should assume that he went to work/bed, and just continue with shutdown.

[Eli-hiw (eli-hiw)]

(In reply to comment #5)
> Confirmed in Ubuntu Jaunty, KDE 4.3.0.
>
> I completely agree with the suggestions thus far. However, I think it would
> also help to put a timeout on the dialog. So if the user doesn't press any
> buttons in, say 30 seconds or 1 minute, the system should assume that he went
> to work/bed, and just continue with shutdown.

I disagree.... Assuming the individual is tired or pressured to get to work, that individual would be prone to forget that he has something important running in a console and if not shutdown properly could screw things up.

If a person does not specifically say go ahead and shutdown the console or click on a check box that says always shutdown / restart, the default behaviour should be to ask and stay on that dialogue box until answered.

[Nemeskey-david (nemeskey-david)]

(In reply to comment #6)
> > However, I think it would also help to put a timeout on the dialog.
>
> I disagree.... Assuming the individual is tired or pressured to get to work,
> that individual would be prone to forget that he has something important
> running in a console and if not shutdown properly could screw things up.
>
> If a person does not specifically say go ahead and shutdown the console or
> click on a check box that says always shutdown / restart, the default behaviour
> should be to ask and stay on that dialogue box until answered.

That is a valid point; there is certainly more to this problem than I imagined. However, I still beg to differ. For one thing, we already have a timeout on startup in Grub. So this is not a novel concept.

There is also the problem of SW/HW. Computers that run important SW are rarely turned off, and most likely not from the GUI; so most likely we are talking about home computers. And in such a case, SW is not such a big deal; but the HW is real. A running computer costs money, consumes electricity unnecessarily and therefore puts a burden on the environment. It can also be dangerous if the user puts it in a bag, thinking it's turned off, while it just gets hotter and hotter inside without proper ventillation.

But anyway, any solution that prevents me for leaving my computer on for a whole day/night accidentally is OK for me.

[Eli-hiw (eli-hiw)]

(In reply to comment #7)
> There is also the problem of SW/HW. Computers that run important SW are rarely
> turned off, and most likely not from the GUI; so most likely we are talking
> about home computers. And in such a case, SW is not such a big deal;

You mean something like yum / apt-get update glibc* xorg* kde* (etc) :)

[Vdboor-f (vdboor-f)]

> You mean something like yum / apt-get update glibc* xorg* kde* (etc) :)

Not relevant:
- if the extra confirmation dialog is already shown when I press shutdown. I'm still behind my computer for 1-2 seconds. It's a good final reminder of "oh oh ... what did I leave running in tty1?".
- your use case requires an experienced computer user who knows a lot more then the general home user.
- if yum or apt-get can't handle a Ctrl+C or other SIGTERM, there is a bigger issue. The shutdown dialog doesn't need to have a workarond for this.

I hope this feature can be implemented as soon as possible. I make jokes like "haha the computer is still on with a 'can't shutdown XYZ' message" about Windows. Well can't do that anymore. ;)

[Eli-hiw (eli-hiw)]

(In reply to comment #9)
> > You mean something like yum / apt-get update glibc* xorg* kde* (etc) :)
>
> Not relevant:
> - if the extra confirmation dialog is already shown when I press shutdown. I'm
> still behind my computer for 1-2 seconds. It's a good final reminder of "oh oh
> ... what did I leave running in tty1?".
> - your use case requires an experienced computer user who knows a lot more then
> the general home user.
> - if yum or apt-get can't handle a Ctrl+C or other SIGTERM, there is a bigger
> issue. The shutdown dialog doesn't need to have a workarond for this.

Its very relevant We're not talking about a workaround for apt-get or yum. The point I was making was that the default behaviour of kdm on shutdown / reboot was to go ahead and do it after a few seconds regardless of what was running in the background (as per comment 7). As you point out the average home user is not as savy as an "experienced user" and does not know or understand that hitting a runlevel 0 or 6 condition and having yum or apt-get halt an update in the middle of lets say updating Xorg could very easily leave XWindows in a state where it will not run or worse, in the case of glibc have the computer not be able to come up at all. And even the inexperienced user updates his or her computer. So having the computer shutdown or reboot without explicitly issuing the command to shutdown open consoles should be a big no no and should not be the default behavior. Especially since KDE has added this really great feature to KDM.

The problem is that is being discussed pertains primarily for "experienced users" that have shutdown all consoles but is warned that a tty session is open even though all of them are closed. The feature requested is that there be a check box or some other mechanism to allow a user to "knowingly" switch off the warning permanently and go ahead and reboot without asking the next time. And just as important, to be able to switch it back on once the bug in upstart is fixed.

Now if you're suggesting that the warning have an option to have it go ahead and shutdown after a certain time period then as an option. I agree this would be a great option. But again, it should not be default. It should be explicitly switched on.

Even though the problem results from a bug in other software, it still doesn't make it any less annoying. If the user changes the default "warning" behavior then its the users problem. If KDE is capable of warning the user that there are consoles open then, it should and it should prevent the shutdown or reboot unless explicitly instructed to do so. If consoles are open then the user should be reminded of it just in case something important is running in them. And by the way even the experienced user gets tired or overwhelmed by whats going on around him. The feature itself is highly welcomed and great addition to KDM.

> I hope this feature can be implemented as soon as possible. I make jokes like
> "haha the computer is still on with a 'can't shutdown XYZ' message" about
> Windows. Well can't do that anymore. ;)

[Eli-hiw (eli-hiw)]

(In reply to comment #10)

Correction to comment. Sorry about the oops.

> Its very relevant We're not talking about a workaround for apt-get or yum. The
> point I was making was that the default behaviour of kdm on shutdown / reboot

The point I was making was that the suggested default behaviour of kdm on shutdown / reboot

> was to go ahead and do it after a few seconds regardless of what was running in
> the background (as per comment 7).

[Vdboor-f (vdboor-f)]

> As you point out the average home user is
> not as savy as an "experienced user" and does not know or understand that
> hitting a runlevel 0 or 6 condition and having yum or apt-get halt an update in
> the middle of lets say updating Xorg could very easily leave XWindows in a
> state where it will not run or worse, in the case of glibc have the computer
> not be able to come up at all.

Question:
- does the average user *EVER* upgrade xorg or glibc?
- which distribution targeting average users gives you rolling upgrades that could possibly contains xorg and glibc?
- how many average users have stuff running in tty's? ;-)

I think you're raising valid questions here, and it would be great if the system can deal with this. (e.g. warn you're still upgrading your system, and therefore you should not shut down).

Currently I'd like to have this feature implemented rather now then later because I can't trust my PC to shutdown properly. I'm a bit concerned we're getting off topic here and thereby preventing the whole feature to become implemented.

All I'm asking for, is showing the "you still have x sessions open" dialog earlier before logging off. Can this be implemented?

Would it be possible to postpone the discussion about "nice/not nice to have a timer" to a second iteration of this feature?

[Vdboor-f (vdboor-f)]

> Currently I'd like to have this feature implemented
Correction: With "this feature" I was actually referring to the original bug report I posted, not the 'package manager interaction' check.

[Eli-hiw (eli-hiw)]

(In reply to comment #12)
> Question:
> - does the average user *EVER* upgrade xorg or glibc?
> - which distribution targeting average users gives you rolling upgrades that
> could possibly contains xorg and glibc?
> - how many average users have stuff running in tty's? ;-)

When updates are made available the package management system will update whatever software is in the update list. So of course they upgrade xorg and glibc when an upgrade is made available for whatever reason; be it for security or bug fix, or new version. Lets not forget to put in the list kdebase, kdelibs, & qt.

The average user will eventually run a tty. If they do not run tty, the first time they upgrade xorg or kdebase, kdelibs or qt, they will be running to the forums and will be told to uninstall the packages mentioned above and then reinstall them in run level 3. So the short answer is yes, they do run tty sessions.

[Jonathan Thomas (echidnaman)]

Hi there,
We are in the process of closing wishlist items that have already been reported at KDE. Don't worry, your issue still is being tracked at KDE's bug tracker at: http://bugs.kde.org/show_bug.cgi?id=183274 . It's just that Kubuntu currently does not have the manpower necessary to take this feature on ourselves. We will receive this functionality once KDE implements it in one of their releases.

Thanks for understanding, and have a nice day.

[Gelefisk (gelefisk)]

Another motivation for solving this bug/feature:
I have a box that I only control via krfb, and as I'm disconnected as soon as I hit the shutdown/restart button, I never see the "active sessions" prompt.

Is there currently no way to bypass this prompt? I've looked into the "Login Manager - KDE Control Module" and manually edited kdmrc (tried setting DefaultSdMode=ForceNow) with no luck.

Running Kubuntu 9.10 and KDE 4.3.5.

[reini (rrumberger)]

(In reply to comment #14)
> The average user will eventually run a tty. If they do not run tty, the first
> time they upgrade xorg or kdebase, kdelibs or qt, they will be running to the
> forums and will be told to uninstall the packages mentioned above and then
> reinstall them in run level 3. So the short answer is yes, they do run tty
> sessions.

You're wrong about this. K/Ubuntu manages to do and finish the upgrades without letting the X server die. Also, debian-based systems don't use runlevels properly, so that "runlevel 3" and tty-based login unfortunately aren't synonymous.
In short: your average Kubuntu user will not likely or ever use a tty.
They can, however, shut down in the middle of an upgrade, leaving their system unusable. KDE can and will not stop this, and KDM can't and shouldn't try to. A user who restarts the system in the middle of an upgrade is in potentially big trouble, and it certainly isn't KDE's job to babysit them.

Then there is my use case: When I trigger a shut down on my laptop I often don't have the time to wait to see whether there will be a prompt. And being stuffed in my backpack as it usually is in this case, having it running will cause hardware damage due to overheating and prolonged exposure to vibrations and shocks (i.e. running to catch the next train).
Whether or not default behaviour should be changed to shut down after a period of time is a different matter and should be discussed in a separate bug report.

[reini (rrumberger)]

*** This bug has been confirmed by popular vote. ***

[Oswald Buddenhagen (ossi-kde)]

*** Bug 217055 has been marked as a duplicate of this bug. ***

[jhansonxi (jhansonxi)]

I'm encountering this bug with Kubuntu 10.04 20100410 (Lucid Lynx) i386. I'm booting it over NFS using PXE. I have no active tty logins, just booting to the desktop then shutdown or restart.

Also, bug #288967 is a probable duplicate.

[rozwell (rozwell69)]

(In reply to comment #6)
> (In reply to comment #5)
> > Confirmed in Ubuntu Jaunty, KDE 4.3.0.
> >
> > I completely agree with the suggestions thus far. However, I think it would
> > also help to put a timeout on the dialog. So if the user doesn't press any
> > buttons in, say 30 seconds or 1 minute, the system should assume that he went
> > to work/bed, and just continue with shutdown.
>
> I disagree.... Assuming the individual is tired or pressured to get to work,
> that individual would be prone to forget that he has something important
> running in a console and if not shutdown properly could screw things up.
>
> If a person does not specifically say go ahead and shutdown the console or
> click on a check box that says always shutdown / restart, the default behaviour
> should be to ask and stay on that dialogue box until answered.

That is true but..

This can have any sense if you work on a single machine with many users in a company or something but not regular users!

I vote to add that checkbox (yet another option in system settings) so we can choose whenever we (DON'T) want to see this annoying prompt.

[Vdboor-f (vdboor-f)]

I didn't ask for a philosophical discussion about all other parts :-)

All I ask for: can the dialog be shown *earlier* in the shutdown process?

All other suggestions deserve another bug report.

[rozwell (rozwell69)]

(In reply to comment #20)
> I didn't ask for a philosophical discussion about all other parts :-)
>
> All I ask for: can the dialog be shown *earlier* in the shutdown process?
>
> All other suggestions deserve another bug report.

I have created request in 247465

[rozwell (rozwell69)]

Can't find any info how to add links to other bugs so sorry for little spam:
#247465
bug 247465
bug #247465

[Christoph-maxiom (christoph-maxiom)]

*** Bug 252405 has been marked as a duplicate of this bug. ***

[Christoph-maxiom (christoph-maxiom)]

*** Bug 270022 has been marked as a duplicate of this bug. ***

[Lamarque (lamarque)]

*** Bug 270022 has been marked as a duplicate of this bug. ***

[Christoph-maxiom (christoph-maxiom)]

*** Bug 271538 has been marked as a duplicate of this bug. ***

[Christoph-maxiom (christoph-maxiom)]

*** Bug 284217 has been marked as a duplicate of this bug. ***

[Christoph-maxiom (christoph-maxiom)]

*** Bug 292890 has been marked as a duplicate of this bug. ***

[Dav1dblunk3tt (dav1dblunk3tt)]

It is annoying for this to occur. IMO it should be optional - I'd turn it off and take my chances.

[Nate-b (nate-b)]

KDM isn't used anymore and there are no new dupes in 10 years. Assuming this is fixed now. :)