Bug 103046 - kdm should disallow multiple concurrent logins of the same user
Summary: kdm should disallow multiple concurrent logins of the same user
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdm
Classification: Unclassified
Component: general (show other bugs)
Version: 3.4
Platform: Compiled Sources All
: NOR wishlist with 76 votes (vote)
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-02 04:52 UTC by Philippe Rigault
Modified: 2018-04-16 20:25 UTC (History)
7 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 Philippe Rigault 2005-04-02 04:52:19 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
Compiler:          GCC 3.4.2 Fedora Core 3 x86_64
OS:                NetBSD

When a user is already logged in a KDE session, Kdm should prevent that same user to start a new KDE session.

Currently, when multiple sessions are enabled or when user activates 'Switch User' -> 'Start New Session', the same user can start several concurrent KDE sessions. This causes undesired behaviour in many places and should be avoided.

Correct behaviour would be to warn with something like:
 "User X already logged in (:0, vt7)"
and add a choice between:
 - Switch to that user's existing session
 - Cancel (come back to kdm), clearing login name.

The warning could be given as soon as the user name is entered (i.e before a password is given).
Comment 1 Rudo Thomas 2005-06-14 15:48:43 UTC
Indeed, a warning would be fine. However, I would add an option to the choices you provided - to really log on. Why ban it completely?
Comment 2 Philippe Rigault 2005-06-15 02:14:48 UTC
> Why ban it completely? 

Because KDE works at the user level, and not at the user+session level.
It supports multiple desktops, but a single session per user.
 
At login time, KDE sets up specific resources in $KDEHOME to ensure proper behaviour throughout a session (this includes reading/creating files, proper logging  such as kdebugdialog, and cleanup). This setup is not supposed to be run several times asynchronously.

In addition, some resources and programs are single-instance resources (e.g kontact), and have a locking mechanism enforced by files in $KDEHOME. 

Here is what will happen with single-instance resources:

my_user logs in session 1, starts kontact
my_user logs in session 2 -> cannot start kontact in this session


In other words, parallel sessions of the same user can interfere pretty badly, including denial of access from one session to the other, messing up files in $KDEHOME, and bogus logging.

Cheers,

Philippe
Comment 3 Oswald Buddenhagen 2005-06-15 07:25:44 UTC
> parallel sessions of the same user can interfere pretty badly
>
these are bugs in the respective applications. multiple sessions of one user is a totally natural thing in unix environments.
Comment 4 Philippe Rigault 2005-06-15 09:03:22 UTC
> multiple sessions of one user
> is a totally natural thing in unix environments.
 
If you mean shell sessions, then sure, _multiple_ instances are a natural thing, but note that multiple shell sessions bring zero guarantee when it comes to data consistency between them, especially when sharing data through files. Two shells reading/writing to the same resource generally result in a total mess.

Precisely because files are the most natural thing in Unix environments, many things cannot be done in multiple mode when atomicity is done through files.

Besides, some processes, in order to guarantee discrete states, cannot allow simultaneity. Think of installing GNU/Linux for example, which could be regarded a some kind of session. Things need to be done according to an exact path, and therefore simultaneous installs from two different media would not be a very good idea.

A desktop requires applications to cooperate in order to give the user some consistency. It is not a bug in kontact to ensure that its components are aware of each other and that some things have to guarantee unicity.

I am not saying that it is not desirable to achieve one day multiple KDE sessions seemlessly (altough I am at a loss currently to identify _one_ situation where multiple sessions would bring someting positive).

However, for now, and as long as KDE maintains the consistency of a desktop session through files in a user-atomic (as opposed to user/tty-atomic) way, it can only do harm to allow for multiple sessions of one user.

Cheers,

Philippe
Comment 5 Philippe Rigault 2005-06-15 09:12:20 UTC
> where multiple sessions would bring someting positive

I meant multiple sessions of the same user, of course.

<off-track>
Because I absolutely _love_ the multiple sessions of independent users which have worked very well since KDE-3.4 and have eliminated the classical fight for resources with kids and wife (all avid KDE fans).
So I take this opportunity to give a big thank you and others for it.

PS: if only switching between sessions would take less time...
</off-track>
Comment 6 Oswald Buddenhagen 2005-06-15 20:36:52 UTC
running multiple instances is definitely a wanted feature - you can have logged in from different (geographically separated) terminals. that's not of interest to the user switching, but the existing bugs have to be fixed anyway. inherently exclusive tasks should provide locks (and, indeed, many do).
also, there might be session types that do not suffer from concurrency problems and i won't restrict them just because some [kde] apps happen to suck in this regard. so a warning is perfectly fine.
another option is of course redesigning the whole switching into a winxp/macosx style one - see bug #89023.
Comment 7 Maciej Pilichowski 2007-08-26 10:49:17 UTC
Anti-vote for this one. I start two session on one user quite often.
Comment 8 Kamil Neczaj 2008-09-19 16:58:07 UTC
(In reply to comment #7)
> Anti-vote for this one. I start two session on one user quite often.

What are benefits? I really don't understand using different sessions for one user. In may opinion using session switching for the same user in console works as taskbar or multiple desktops in kde, and nothing more.

Small comparison to console where multiple sessions of one user are usefull:

Using only one console session:
1. Lack of multitasking.
2. Only one workspace
3. Similar memory using

Using only one kde session:
1. Full multitasking
2. Multiple desktops (workspaces)
3. Smaller memory using

So what do you want more? Is there any drawback of using one session of kde (maybe common to single console and kde session)?

I'm really in favour of Mac/Windows solution, it hasn't any disadvantages, but simplyfies user switching, limit memory using and prevent "undesired behaviour" as it mentioned in the bug report.
Comment 9 Kamil Neczaj 2008-09-19 17:05:42 UTC
> I'm really in favour of Mac/Windows solution
And fixing that bug means getting closer to it.
Comment 10 Kamil Neczaj 2008-09-19 17:09:50 UTC
> Using only one console session: 
> 1. Lack of multitasking. 
> 2. Only one workspace 
> 3. Similar memory using 
> Using only one kde session: 
> 1. Full multitasking 
> 2. Multiple desktops (workspaces) 
> 3. Smaller memory using 

The memory using is a comparison to multiple sessions of the same user
Comment 11 Horst Schirmeier 2010-03-04 21:14:53 UTC
I have a dual head setup for which I definitely need two concurrent logins of the same user.  Don't forbid that by design.
Comment 12 Oswald Buddenhagen 2010-03-24 17:32:44 UTC
see bug 212079 for some musings.

the dual head case seems bogus. the heads should be separate seats (per ConsoleKit speak) and thus have independent session lists (though a warning like "you already have a session open on another seat" would still be in order).
Comment 13 Maciej Pilichowski 2010-03-25 17:11:25 UTC
Let me revert the question -- what is the purpose of blocking this feature?

I am afraid seeing this approach again and again -- something is technically OK, but we (KDE dev team) disable it. Just in case. The problem is, when the user is in trouble all she/he can do (real life scenario) is to report a bug, wait some time (from week to several years) and then see it fixed. But the problem user has should be resolved _now_ not later, sometime in future.

If the feature has to be implemented as extra, sure, it take time to do it, but disabling something what exists -- it is completely unreasonable. You cannot predict all cases, so it should be open for future uses, not closed.

And just mine case -- I simply need to check this or that on my account without interrupting my current work. And since I do quite amount of testing the only workaround -- creating fake account and copying data/settings/etc to this account from my real one -- is simply tiresome. 
It was just my case, it is not an argument pro, per se.
Comment 14 Jamie Thompson 2010-04-29 19:44:06 UTC
As much as it pains me to say it, the Windows way of handling this on desktops is IMHO current the best - a user list with a simple status display showing that they are already logged in, which resumes their session when they log back in.

Now of course, being able to start additional sessions is the sort of advanced feature that makes Linux great, but it is a power-user feature, not a common use scenario for 90 of users.

Perhaps a workable solution could be that if a user already has a session then a check box appears under the username and password fields that enables them to start a new session. If unchecked (aka. a normal login) and the user already has multiple sessions to resume, a list of the user's sessions could be displayed which they could then choose which to resume from.

As functional as it is, the CTRL+ALT+Fn combos in use are not intuitive in the slightest to all of the normal users I've tried to explain them to (if for nothing else then they have no idea which order others have logged in, so have no idea which combo to use as there are no visual indications of this anywhere).

IHMO, ideally as much should be able to be accomplished as possible with just the mouse, and always catering for the most prevalent use case.
Comment 15 Brandon Watkins 2013-08-18 20:13:05 UTC
Here we are, 2013 and kde 4.11 and I still see this issue, this is pretty ridiculous... I love KDE but its handling of multi-user switching is the worst I have ever seen in any operating system. Its buggy, inconsistant, and completely unintuitive. 

Will this ever be fixed? Why on earth does kdm default to starting a new session when a that user is already logged into a session, why is that even possible? no one would EVER want to do that, it makes no sense. 
/rant

For any user that isn't familiar with KDE's user switching insanity they would be completely lost...
Comment 16 Tobias Leupold 2013-11-19 10:45:51 UTC
I would really appreciate to see this issue fixed or integrated in kdm.

I ran into problems at work, as one of my employees accidentally started a second graphical KDE session after switching a user (instead of just switching back to the first session). The result was that KMail had been stared twice and the second Instance downloaded mails as well as the first one, causing collisions in my local maildir (and nobody knew why ;-).

I think it would not really be necessary to forbid multiple graphical logins per user completely. But I think at least a warning should pop up, asking the user if he actually wants to create a second (or third …) graphical session or rather switch to the already open one.
On the other hand, one could simply make a checkbox in systemsettings teeling if or if not to allow multiple graphical logins. Perhaps also a second one if a warning should be displayed or not.

I don’t think that opening multiple graphical sessions is what most users want to.
Comment 17 Tobias Leupold 2013-11-19 10:46:48 UTC
*** This bug has been confirmed by popular vote. ***
Comment 18 Tobias Leupold 2014-05-07 06:16:57 UTC
Is anybody working on this? This bug has been around for over 9 years now(!), and nothing happened …

It's really annoying when the default behavior is not even to warn when a user unintentionally starts multiple graphical sessions for one and the same user, especially on a true multi-user OS like Linux that is actually used by multiple users.

Please fix this!
Comment 19 Christoph Feck 2014-06-10 22:27:28 UTC
Tobias, the current maintainer is not working on this. If this bug is important to you or your company, you could hire a freelance developer to fix it.
Comment 20 Tobias Leupold 2014-06-11 10:38:18 UTC
> the current maintainer is not working on this
Why?! 19 comments on a 9 year old bug and the maintainer is not interested to fix it? Is there a good reason for not fixing this bug? The argumentation above why kdm should change it's current behavior is completely reasonable to me. I think the only reason why not more people request this is that most KDE installations are single-user ones so most of the user don't run into this and simply don't notice this bug/feature lack.

Well … I don't work at a (IT) company, I'm just a dentist with personal not being as fit as me in IT ;-) I'll have a look at the sources. Perhaps, I can fix it myself (although I don't code much Qt/C++/KDE).

Anyways, this shouldn't be too hard to fix, should it? A simple warning popping up would already be sufficient.
Comment 21 Christoph Feck 2014-07-21 17:03:43 UTC
Tobias, kdm is long in a state where only critical fixes are applied. For Plasma 5, it has even been dropped.

Maybe other display managers offer this feature already? Try to replace it with lightdm or sddm.
Comment 22 Tobias Leupold 2014-07-21 17:15:58 UTC
Has been dropped in favor of what?! There's no default KDE login manager now anymore?!
Comment 23 Christoph Feck 2014-08-18 12:58:26 UTC
It has not been dropped in favor, but because nobody was willing to port the code to Qt5+KF5. As with all free software, to keep it alive requires someone caring.
Comment 24 Tobias Leupold 2014-08-24 14:51:58 UTC
So what is the official recommendation to use instead?
Comment 25 Nate Graham 2018-04-16 20:25:48 UTC
KDM is unmaintained and not used in KDE Plasma 5.

SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/