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).
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?
> 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
> 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.
> 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
> 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>
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.
Anti-vote for this one. I start two session on one user quite often.
(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.
> I'm really in favour of Mac/Windows solution And fixing that bug means getting closer to it.
> 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
I have a dual head setup for which I definitely need two concurrent logins of the same user. Don't forbid that by design.
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).
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.
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.
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...
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.
*** This bug has been confirmed by popular vote. ***
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!
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.
> 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.
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.
Has been dropped in favor of what?! There's no default KDE login manager now anymore?!
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.
So what is the official recommendation to use instead?
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/