Bug 183274 - KDM should offer "close active sessions" confirmation dialog earlier
Summary: KDM should offer "close active sessions" confirmation dialog earlier
Status: RESOLVED FIXED
Alias: None
Product: ksmserver
Classification: Plasma
Component: general (show other bugs)
Version: 4.7.x
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
: 217055 252405 270022 271538 284217 292890 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-05 09:20 UTC by Diederik van der Boor
Modified: 2020-09-29 03:42 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Diederik van der Boor 2009-02-05 09:20:27 UTC
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.
Comment 1 Ildar Nurislamov 2009-03-07 12:28:57 UTC
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.
Comment 2 Oswald Buddenhagen 2009-03-15 13:55:05 UTC
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.
Comment 3 Ildar Nurislamov 2009-06-20 22:28:12 UTC
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"
Comment 4 David Nemeskey 2009-08-30 16:53:35 UTC
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 )"
Comment 5 David Nemeskey 2009-08-30 16:57:23 UTC
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.
Comment 6 eli 2009-08-30 19:44:43 UTC
(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.
Comment 7 David Nemeskey 2009-08-31 20:26:41 UTC
(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.
Comment 8 eli 2009-08-31 21:49:38 UTC
(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) :)
Comment 9 Diederik van der Boor 2009-09-13 20:12:38 UTC
> 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. ;)
Comment 10 eli 2009-09-13 22:23:09 UTC
(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. ;)
Comment 11 eli 2009-09-13 22:30:38 UTC
(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).
Comment 12 Diederik van der Boor 2009-09-18 00:53:12 UTC
> 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?
Comment 13 Diederik van der Boor 2009-09-18 00:55:00 UTC
> 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.
Comment 14 eli 2009-09-18 07:20:52 UTC
(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.
Comment 15 gelefisk 2010-03-06 11:42:57 UTC
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.
Comment 16 ancow 2010-04-02 12:08:49 UTC
(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.
Comment 17 ancow 2010-04-02 12:12:04 UTC
*** This bug has been confirmed by popular vote. ***
Comment 18 Oswald Buddenhagen 2010-04-07 00:35:02 UTC
*** Bug 217055 has been marked as a duplicate of this bug. ***
Comment 19 rozwell 2010-08-12 05:11:17 UTC
(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.
Comment 20 Diederik van der Boor 2010-09-01 22:51:30 UTC
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.
Comment 21 rozwell 2010-09-01 23:03:08 UTC
(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
Comment 22 rozwell 2010-09-01 23:07:04 UTC
Can't find any info how to add links to other bugs so sorry for little spam:
#247465
bug 247465
bug #247465
Comment 23 Christoph Feck 2010-09-26 13:15:45 UTC
*** Bug 252405 has been marked as a duplicate of this bug. ***
Comment 24 Christoph Feck 2011-04-04 01:21:19 UTC
*** Bug 270022 has been marked as a duplicate of this bug. ***
Comment 25 Lamarque V. Souza 2011-04-04 19:03:38 UTC
*** Bug 270022 has been marked as a duplicate of this bug. ***
Comment 26 Christoph Feck 2011-04-29 19:32:35 UTC
*** Bug 271538 has been marked as a duplicate of this bug. ***
Comment 27 Christoph Feck 2011-10-17 10:08:17 UTC
*** Bug 284217 has been marked as a duplicate of this bug. ***
Comment 28 Christoph Feck 2012-01-31 00:10:04 UTC
*** Bug 292890 has been marked as a duplicate of this bug. ***
Comment 29 davidblunkett 2012-03-24 19:40:32 UTC
It is annoying for this to occur.  IMO it should be optional - I'd turn it off and take my chances.
Comment 30 Nate Graham 2020-09-29 03:42:07 UTC
KDM isn't used anymore and there are no new dupes in 10 years. Assuming this is fixed now. :)