GNOME Bugzilla – Bug 83835
gnome-session doesn't handle multiple concurrent logins
Last modified: 2014-12-15 21:02:20 UTC
There's no locking on the session file, right?
no, no locking. there's more than this that needs to be fixed for multiple sessions to work. g-s-d needs to store stuff per-display / session somehow, and the panel needs to not dump things in the default.
Before I mark this major/High- does anyone actually use this? Have we ever claimed to support it?
i don't think so. it's never really worked, at least as of gnome 1.0.50
It's never really worked but it's always been a common user complaint/issue. At least I've heard about it from customers, and e.g. the Linux terminal server project.
+1 i'd like to vote on this one getting fixed.
I think that this is quite an important resolution that needs to be made. The only reason that I'm using KDE on a spare machine, is because of the ability to run it on display :0 AND :1 as the same user. Lacking this ability makes it seem like GNOME (gnome-session) specifically is going backwards in the usefuless category. I, personally would use it extensively if the option were given to me, and I'm sure many other users would agree.
Okay - what exactly is the problem here? There's no locking on the session file - I get that, but thats not a huge issue. What else prevents users from being logged in multiple times? I know we (in Sun) do it the whole time on SunRays. There are some teething issues, but overall it works okay ...
I am logged into multiple machines under the same user id every day, but I can only use my favorite window manager (GNOME) on one machine. I would LOVE to see this implemented. I was very surprised to find out that GNOME didn't support this.
I think it would be enough to first "disable" concurrent logins of the same user to GNOME via some simple locking mechanism, and then, if requested/possible, to allow it. I have multiple users in my company using GNOME and the're complaining about "missing icons from desktop", which is likely symptom of being logged more than one time to GNOME. (We are using Sun Rays with card readers and session cards, so it is perfectly simple for an user to log in twice: one time with and one time without his/her session card). Anybody ever thinking of fixing this?
Well, I have put this in garnome-session script file, which runs gnome-session at the end: [snip] GARNOME=/opt/BGSgnome-2.6.2 # Check if we are running. Filter garnome-session in process list for current # user and exit, if garnome-session is running. pgrep -u $LOGNAME $GARNOME/garnome-session if [ $? -eq 0 ]; then echo "Warning: garnome-session already running, exiting."; exit 0; fi PATH=$GARNOME/bin:/usr/sfw/bin:$PATH:/usr/openwin/bin [rest] This workaround seems to work fine, testing on Solaris. Get GARNOME's README file to check original garnome-session script.
Former session-script fragment is buggy: The pgrep line should be: pgrep -f -u $LOGNAME $GARNOME/gnome-session Sorry for inconvenience, I've found this only two days ago. Wondering if anybody has some kind of better solution, i.e. not in the session script.
Ivan, the sunray environment where users login more than once and not getting the right icons etc is because the way bonobo-activation-server has already registered when the user first login but the services handler is on a per user basis and not per display, hence the problem. http://bugzilla.gnome.org/show_bug.cgi?id=94049 proposes a per display mechanism for gnome-settings-daemon and that should resolve most of the problem you seen. -Ghee
Thanks Ghee; I'm not maintaining my GNOME build environment anymore (for couple of months I simply don't have time for that). I'm just interested, if you have tried the solution and what GNOME release is it for. Sun's GNOME (2.0.x) or 2.8? HEAD (2.9)? Many thanks!
*** Bug 317189 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > I think it would be enough to first "disable" concurrent logins of the same user > to GNOME via some simple locking mechanism, and then, if requested/possible, to > allow it. I believe this is the most acceptable way. Using LTSP in Edubuntu we often faced the problem.
There are many issues with logging in more than once, spawning multiple components. dconf won't work over nfs without being started in special mode, gconf before that would corrupt its own state file if two clients were mucking with it over NFS at the same time. There are other issues too. We're not likely to fix that any time soon if the last 12 years of inactivity on this bug are any indicator. I'm going to close this one out... But anyone who strongly disagrees can feel free to reopen.