X2Go Bug report logs - #631
develop X2Go Server session manager

Toggle useless messages

Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: submit@bugs.x2go.org

Subject: NX agent dies not reliably remove socket files under /tmp/.X11-unix

Date: Thu, 02 Oct 2014 18:05:23 +0200

Package: nxagent
Version: 3.5.0.27
Severity: important

17:02 < bigfoot-> hmmm.  x2goagent is started with  -extension XFIXES 
                  -nolisten tcp -nolisten tcp -dpi 96 -D -auth 
                  /fs/staff/hsc/.Xauthority -geometry 800x600 -name 
                  X2GO-hsc-51-1412262126_stDmyxfce_dp24 :51
17:02 < bigfoot-> :50 is the already running (first) session
17:03 < bigfoot-> and x2goagent dies with 
                  https://pbot.rmdir.de/tt64QL-NNXqZomZoahDhJg

[...]

17:08 < bigfoot-> woglinde: I had to remove remaining /tmp/.X*-lock and 
                  /tmp/.X11-unix/X* that were owned by other users.  Works 
                  like a charm again now.
17:09 < bigfoot-> iow, a reboot would've helped, too (if it cleans up /tmp, 
                  that is).  but that's a non-option on this machine.

[...]

17:23 <@sunweaver> please report it as a bug!!!!
17:24 < bigfoot-> I'm still investigating; seeing this issue again now.  The 
                  process is as follows:
17:25 < bigfoot-> - some user logs in, gets :50
17:25 < bigfoot-> - some user logs in, gets :50
17:25 < bigfoot-> - /tmp/.X50-lock and /tmp/.X11-unix/X50 are owned by him now
17:25 < bigfoot-> - user logs out, which doesn't succeed completely (due to 
                  some yet unknown reason; he's got a default xfce setup in 
                  his home)
17:26 < bigfoot-> - user logs in via ssh and kills all his processes via  
                  killall -u username
17:26 < bigfoot-> afterwards, x2go seems to assume :50 is free, but the two 
                  aforementioned files still exist
17:26 < bigfoot-> the next user gets assigned :50, but this fails as the user 
                  doesn't have the permissions to access these files
17:27 < bigfoot-> So, who (or, which part of x2go) is responsible for removing 
                  these files?  When does/should this happen?



17:51 < bigfoot-> sunweaver: this change seemingly only changes the output, 
                  does this have an effect on the cleanup stuff?
17:51 <@sunweaver> no
17:51 <@sunweaver> the fix is four smoothing out mkigration from 4.0.1.15 to 
                   higher...
17:52 <@sunweaver> though there could be unexpected side effects...
17:52 <@sunweaver> there also is a patch in NX I introduced lately...
17:53 < bigfoot-> ok, but how should the new x2golistsessions and 
                  x2golistsessions_root affect my issue with cleanup?
17:55 <@sunweaver> http://code.x2go.org/gitweb?p=nx-libs.git;a=blob;f=debian/patches/027_nxcomp_abstract-X11-socket.full%2Blite.patch;h=4f614338cd51e19e05de87d097d623065d826d56;hb=bddc7e0ba4cef393ce56f75d1eb03255fe5ac6e1


-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976148

GnuPG Key ID 0x25771B13
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

Message #10 received at 626@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 626@bugs.x2go.org

Subject: rather a post-cleanup issue in x2gocleansessions

Date: Thu, 02 Oct 2014 20:58:55 +0200

Control: reassign -1 x2goserver
Control: retitle -1 NX socket cleanup post-session
Control: severity -1 wishlist

Hi,

there was more insight on IRC which turns this bug into a feature request for x2gocleansessions:

8:19 < bigfoot-> it seems the aforementioned #1 reproducer killed his nxagent via kill -9.  could 
                  this be the reason that his /tmp/.X* stuff wasn't cleaned up?  shouldn't 
                  x2gocleansessions clean this up anyways?
18:22 < bigfoot-> regarding your patch, as on my system actual files (/tmp/.X50-lock, 
                  /tmp/.X11-unix/X50) are used instead of this "abstract socket" stuff, I guess it 
                  doesn't have anything to do with my problems, right?
18:22 <@sunweaver> sure, that can be the reason!!!
18:23 <@sunweaver> kill -9 does forbid any sort of callback, so socket file removal does not 
                   happen....
18:23 < bigfoot-> that I definitely do understand, but what is x2gocleansessions there for then?

--> x2gocleansession should check if X<disp> socket files in /tmp/.X11-unix have got cleanly removed on nxagent shutdown and if not it should handle the post-session cleanup of those socket files.

Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976148

GnuPG Key ID 0x25771B13
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

Message #23 received at 626@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 626-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 626@bugs.x2go.org

Subject: X2Go issue (in src:x2goserver) has been marked as pending for release

Date: Fri, 3 Oct 2014 12:38:41 +0200 (CEST)

tag #626 pending
fixed #626 4.0.1.17
thanks

Hello,

X2Go issue #626 (src:x2goserver) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:

    http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=5231443

The issue will most likely be fixed in src:x2goserver (4.0.1.17).

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
commit 52314435eb78a79ea0622450a691a1f672f9d39f
Author: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Date:   Fri Oct 3 12:33:24 2014 +0200

    Handle stale X11 socket files in cases where x2goagent has mysteriously disappeared (e.g. kill -9). (Fixes: #626).

diff --git a/debian/changelog b/debian/changelog
index 882863a..cf332b4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,8 @@ x2goserver (4.0.1.17-0x2go1) UNRELEASED; urgency=medium
   * New upstream release (4.0.1.17):
     - Fix breakage of X2Go Server when upgrading from 4.0.1.15 while
       sessions are still in running / suspended state. (Fixes: #623).
+    - Handle stale X11 socket files in cases where x2goagent has
+      mysteriously disappeared (e.g. kill -9). (Fixes: #626).
 
  -- Mike Gabriel <mike.gabriel@das-netzwerkteam.de>  Thu, 02 Oct 2014 12:18:58 +0200
 

Message #35 received at 626@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 626-submitter@bugs.x2go.org

Cc: control@bugs.x2go.org, 626@bugs.x2go.org

Subject: X2Go issue (in src:x2goserver) has been marked as closed

Date: Fri, 3 Oct 2014 17:35:43 +0200 (CEST)

close #626
thanks

Hello,

we are very hopeful that X2Go issue #626 reported by you
has been resolved in the new release (4.0.1.17) of the
X2Go source project »src:x2goserver«.

You can view the complete changelog entry of src:x2goserver (4.0.1.17)
below, and you can use the following link to view all the code changes
between this and the last release of src:x2goserver.

    http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=6b428c94f421bc5ee21dc40b8507d84172dd7734;hp=ddbb2f0df266094ccdc61bee00e0b955a4e08c4f

If you feel that the issue has not been resolved satisfyingly, feel
free to reopen this bug report or submit a follow-up report with
further observations described based on the new released version
of src:x2goserver.

Thanks a lot for contributing to X2Go!!!

light+love
X2Go Git Admin (on behalf of the sender of this mail)

---
X2Go Component: src:x2goserver
Version: 4.0.1.17-0x2go1
Status: RELEASE
Date: Fri, 03 Oct 2014 17:09:23 +0200
Fixes: 623 626
Changes: 
 x2goserver (4.0.1.17-0x2go1) RELEASED; urgency=medium
 .
   * New upstream release (4.0.1.17):
     - Fix breakage of X2Go Server when upgrading from 4.0.1.15 while
       sessions are still in running / suspended state. (Fixes: #623).
     - Handle stale X11 socket files in cases where x2goagent has
       mysteriously disappeared (e.g. kill -9). (Fixes: #626).
     - Make sure that incompletely started up sessions get wiped from the
       session DB after 10 seconds.
     - Fix unreliable removal of client-side folder sharing desktop
       icons.
     - Update date in several man pages.
   * debian/control:
     + Upgrade x2goserver-xsession from Suggests: to Recommends:.

Message #47 received at 626@bugs.x2go.org (full text, mbox, reply):

From: Horst Schirmeier <horst@schirmeier.com>

To: 626@bugs.x2go.org

Subject: Re: NX agent dies not reliably remove socket files under /tmp/.X11-unix

Date: Fri, 3 Oct 2014 21:47:21 +0200

OK, to summarize the scenario:
 
 -  A normal user connects, gets the first display :50, runs his
    session.  /tmp/.X50-lock and /tmp/.X11-unix/X50 are owned by this
    user.
 
 -  The user decides to killall -u username -9.  (Don't ask.  The
    actual story was that the logout process didn't complete, and he
    tried to clean up behind him, having accustomed to use kill -9 all
    the time.)
 
 -  This kicks the user's nxagent out of business (the same would happen
    if it simply crashes), which prevents it from cleaning up the
    sockets in /tmp.

 -  Another user connects, and also gets assigned the first display
    (because, for some reason, x2go is convinced it's free again).  His
    x2go processes are not permitted to remove and recreate
    /tmp/.X50-lock and /tmp/.X11-unix/X50, and the window manager dies
    immediately.  All users besides the initial user are locked out of
    x2go from now on.
 
Manual workaround: Remove stale /tmp/.X??-lock and /tmp/.X11-unix/X??.
Apply LART to users of kill -9 against nxagent.

Automatic workaround: x2gocleansessions should probably take care of the
/tmp file removal.  LART will still need to be applied manually.

A "real" fix would move the usual, immediate cleanup step out of the
user's control.  This could, for example, happen by a daemon running as
root, that spawns a nxagent at a user's request, under the user's UID.
Once the nxagent dies (from whatever cause), the daemon's SIGCHLD
handler does the cleanup.  This would also remove the race condition (up
to 2s delay before the sockets are cleaned up; connection of new users
may be impossible in this time window) introduced by the aforementioned
"automatic workaround".

Another, much simpler possibility would be to use randomized/uniqe
socket names instead of the fixed /tmp/.X${DISPLAYNUM}-lock /
/tmp/.X11-unix/X${DISPLAYNUM} scheme.  But I don't know enough about X11
to judge whether this could work.

-- Horst

-- 
PGP-Key 0xD40E0E7A

Message #52 received at 626@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: Horst Schirmeier <horst@schirmeier.com>, 626@bugs.x2go.org

Subject: Re: [X2Go-Dev] Bug#626: NX agent dies not reliably remove socket files under /tmp/.X11-unix

Date: Fri, 03 Oct 2014 22:36:45 +0000

[Message part 1 (text/plain, inline)]

Control: clone -1 -2 -3
Control: reopen -2 -3
Control: retitle -2 clean up stable /tmp/.X<disp>-lock files
Control: retitle -3 develop X2Go Server session manager
Control: severity -2 important
Control: severity -3 wishlist

On  Fr 03 Okt 2014 21:47:21 CEST, Horst Schirmeier wrote:

> Automatic workaround: x2gocleansessions should probably take care of the
> /tmp file removal.  LART will still need to be applied manually.

This is partly already implemented in X2Go Server 4.0.1.17. However, I  
missed providing some code that removes the /tmp/.X<disp>-lock file.  
For this I have clone a new bug with the title "clean up stable  
/tmp/.X<disp>-lock files". I won't be working on X2Go over the  
weekend, so from anyone else: patches are welcome.

> A "real" fix would move the usual, immediate cleanup step out of the
> user's control.  This could, for example, happen by a daemon running as
> root, that spawns a nxagent at a user's request, under the user's UID.
> Once the nxagent dies (from whatever cause), the daemon's SIGCHLD
> handler does the cleanup.  This would also remove the race condition (up
> to 2s delay before the sockets are cleaned up; connection of new users
> may be impossible in this time window) introduced by the aforementioned
> "automatic workaround".

This actually is something we plan for X2Go Server 5.0. There will be  
a session management daemon that the clients talk to and the session  
management daemon will take care of all the (internal) actions to  
provide what clients request. The session management daemon will be  
virtually in charge of everything X2Go-related and it will be  
event-based and all-knowing.

This feature request will be dealt with as a new bug, titled: "develop  
event-based X2Go Server session manager"

> Another, much simpler possibility would be to use randomized/uniqe
> socket names instead of the fixed /tmp/.X${DISPLAYNUM}-lock /
> /tmp/.X11-unix/X${DISPLAYNUM} scheme.  But I don't know enough about X11
> to judge whether this could work.

In theory this could be possible, but it would interfere a great deal  
with what other X11-related applications / libraries expect. So, this  
actually is a no-go IMHO.

Greets,
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Message #65 received at 631@bugs.x2go.org (full text, mbox, reply):

From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>

To: 631@bugs.x2go.org

Subject: No session manager planned, closing...

Date: Mon, 08 Jan 2024 19:51:52 +0000

[Message part 1 (text/plain, inline)]

Control: close -1
Control: tag -1 wontfix

There is no session manager planned for X2Go midterm. Closing this  
feature request for now.
-- 

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.