Package: killer
Severity: serious

Hi,

since Debian jessie, we disable killer in Debian Edu installations as
killer causes hourly logouts from user sessions.

We never came to the point to investigate this closer, but personally,
I think that killer on a Debian Edu system with MATE desktop env has
not been usable at least since jessie.

Mike

[Mike Gabriel]

The only way I can think of that this can happen, is if the display
manager is broken and fail to register logged in users in the utmp/wtmp
files.  You can verify this by running 'w' or 'who' after login to see
if the user is registered as logged in.  If this is the case, the fatal
bug is in the login service you are using, not killer.

[Mike Gabriel]

The only way I can think of that this can happen, is if the display
manager is broken and fail to register logged in users in the utmp/wtmp
files.  You can verify this by running 'w' or 'who' after login to see
if the user is registered as logged in.  If this is the case, the fatal
bug is in the login service you are using, not killer.

Output of "who" looks good, if MATE gets launched locally (vt7).
Display Manager is LightDM with Arctica Greeter on top.

However, I noticed that X2Go does not register the logged in user in
utmp/wtmp.

Mike

I'm unable to reproduce the reported issue (Debian Edu Jessie, Stretch,
Buster; tested LightDM, GDM, SDDM).

Mike, could you provide some details?

IIRC, for connections to a system that runs Nomachine technology (not
part of Debian) the utmp/wtmp files are not used by design (on the
system running NX server). Instead, NX keeps track of the
forwarded sessions itself.

IMO killer shouldn't be installed on a system running NX technology
because the reported failure will show up for sure.

Wolfgang

[Wolfgang Schweer]

Updating utmp/wtmp is not only for 'keeping track of sessions', it is
also used by shutdown and other systems to know who to notify when
taking down a host or notify logged in users in other cases.  If NX do
not update utmp/wtmp for logged in users, I would claim that NX is
broken, and if it is by design, then NX is broken by design.

Yes, I know. This has been an issue years ago when I used freeNX (the
first open source NX server implementation) at school; it was always
needed to care for it manually using some tool to list running sessions.
It doesn't seem to have been improved with recent implementations.

Right. This bug should be reassiged to the x2go-server package, but then
the package isn't part of Debian...

Wolfgang

See: https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1171

Wolfgang

After testing x2goserver on a Stretch system I noticed that X2Go
sessions can be detected reliably due to some command using a param
string containing 'X2GO'.

This change would work around the x2go bug running the killer cron job
only in case an X2Go session isn't detected:

--- a/cron.hourly	2014-06-11 11:15:55.000000000 +0200
+++ b/cron.hourly	2018-02-22 19:42:36.419963949 +0100
@@ -1,3 +1,3 @@
 #!/bin/sh

After testing x2goserver on a Stretch system I noticed that X2Go
sessions can be detected reliably due to some command using a param
string containing 'X2GO'.

This change would work around the x2go bug running the killer cron job
only in case an X2Go session isn't detected:

--- a/cron.hourly	2014-06-11 11:15:55.000000000 +0200
+++ b/cron.hourly	2018-02-22 19:42:36.419963949 +0100
@@ -1,3 +1,3 @@
 #!/bin/sh

Hi Wolfgang,

This is at most a dirty work around. The killer command wipes
x2goagent hourly and this must be prevented in killer itself somehow.

With the above patch you disable killer system-wide once at least one
X2Go Session is running on the host. Not the right approach.

Mike

control: severity -1 important
# x2go-server is not in Debian, this lowering the severity…
thanks

we could still make the killer package conflict with it… or add a
Breaks.

(But that too would be a workaround…)

[Mike Gabriel]

It do not sound like a too bad approach either, given that X2Go fail to
register its sessions in the standard unix way.  It seem like the safe
option to just disable killer if X2Go is detected.

sessions (similar like the 'condor' ones) for the time being.

Users with active X2Go sessions can be identified running:
'ps aux | grep '[x]2goruncommand' | cut -d ' ' -f1'

Mike, could you test this change to killer (might be smarter, some one
w/ Perl skills should check it:
--- a/killer	2018-02-27 18:14:50.085187798 +0100
+++ b/killer	2018-02-27 18:15:59.624571678 +0100
@@ -1328,6 +1328,23 @@

 =item *

+Exclude all jobs belonging to users running an X2Go session from being
+terminated. X2Go fails to register users in utemp/wtemp files; for more
+information, see: https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1171
+
+=cut
+
+    my @x2gousers = ();
+    foreach my $pid ( keys %pid2comm ) {
+        next unless ( $pid2comm{$pid} eq 'x2goruncommand' );
+        push(@x2gousers, $pid2user{$pid});
+    }
+    foreach $user ( @x2gousers ) {
+        $ptable->removeProcesses('ruser', $user);
+    }
+
+=item *
+
 Finally, the process table and terminal objects are returned.

 =back


Wolfgang

sessions (similar like the 'condor' ones) for the time being.

Users with active X2Go sessions can be identified running:
'ps aux | grep '[x]2goruncommand' | cut -d ' ' -f1'

Mike, could you test this change to killer (might be smarter, some one
w/ Perl skills should check it:
--- a/killer	2018-02-27 18:14:50.085187798 +0100
+++ b/killer	2018-02-27 18:15:59.624571678 +0100
@@ -1328,6 +1328,23 @@

 =item *

+Exclude all jobs belonging to users running an X2Go session from being
+terminated. X2Go fails to register users in utemp/wtemp files; for more
+information, see: https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1171
+
+=cut
+
+    my @x2gousers = ();
+    foreach my $pid ( keys %pid2comm ) {
+        next unless ( $pid2comm{$pid} eq 'x2goruncommand' );
+        push(@x2gousers, $pid2user{$pid});
+    }
+    foreach $user ( @x2gousers ) {
+        $ptable->removeProcesses('ruser', $user);
+    }
+
+=item *
+
 Finally, the process table and terminal objects are returned.

 =back


Wolfgang

[Wolfgang Schweer]

I had a look at the patch, and it is not obviously wrong, at least.  I do
not know the code well any more, but did test and read it, and it might
work.  I do not have x2go myself, so I can not test that part, though.

Hi Wolfgang,

I am not sure, if the patch is not a functional overkill. My
observation was, that the x2goagent processes got killed by killer.

So maybe, we should protect those only. For the session applications,
I am currently working on a sessreg based utmp/wtmp patch against X2Go
Server.

I'll provide more info later today.

Mike

Thanks for the feedback. I've now tested the patched killer script once
again in a virtual machine environment: X2Go server running on a Debian
Edu Buster combined server, X2Go Client on a Debian Edu Buster
workstation with profile 'Standalone'. The complete set of X2Go
component packages is available in testing since March 2018.

The killer script works like expected.

A git format-patch is attatted, generated against killer.git as of
today.

Wolfgang

Hi Mike,

I don't think that this is the case:

Yes, but if the user's x2goagent process gets killed, all other
processes belonging to this user will be killed as well because the user
session isn't registered. OTOH stale x2goagent processes may still exist
from sessions that have been messed up by the user. At least this
has been the case when I used NX technology at school to let people
connect from home. (Years ago, though, things might be different
nowadays.)

IMO stale x2goagent processes should be killed.
That's why the patch searches for users with a x2goruncommand process.
If this one exists, user applications are actually running and nothing
belonging to these users should be killed.

That sounds very good. Patching the killer script would be obsolete in
that case.

Wolfgang

Hi Wolfgang,

No. The other processes get killed because most of them are X clients
to x2goagent (which is a nested Xserver). Once x2goagent is gone, the
attached X clients evaporate.

Yeah, I know. This should be cleanly handled by the x2gocleansessions
script running in the background on all X2Go Servers (launched by
x2goserver.service).

It should not be on us (i.e. killer) to clean up that X2Go specific
mess. So, stale x2goagent instances can be ignored here.

  -> /usr/sbin/x2gocleansessions, not for us.

This is true. If we (speaking with my X2Go upstream hat and Debian Edu
hat on) want time-limited X2Go sessions, than this bit of code should
really go into X2Go Server. I agree on the above.

I have chewed on different approaches yesterday (and was not too
happy). This morning I came up with a solution that I need to propose
to the X2Go upstream team (once the patch works 100%).

I am quite positive and assume that we will get this into buster.

Mike

control: severity -1 serious
# x2go-server is now in buster
thanks

cu
Adrian

control: reassign -1 x2goserver
thanks

right, thanks for raising the severity.

I agree with this.

I don't really agree with this (which I wrote) anymore. x2goserver should be
fixed to update utmp/wtmp.

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Hi Adrian,

neither x2goserver nor killer are unusable due to the missing
utmp/wtmp registration. Thus, reducing severity to imporant.

I will look into this issue for buster is out while we are still in
soft-freeze (in fact I have some local prototype already, but need to
revisit).

Mike

Moin Mike,

Any news on this one? Debian Edu Bullseye intends to use x2goserver on
LTSP servers for Thin Client support...

Wolfgang

[Wolfgang Schweer]

The upstream issue is still open, at least.

(Just a quick reply to set the forwared url. :)

-- 
Hello,
is my pleasure meeting with you, please something came up and i really
want to discuses with you urgent and important