systemd user session not always created

[xhernandez]

I'm using version 0.9.2 on an Ubuntu Mate 16.04.2 LTS and apparently everything works fine. However I've seen that sometimes systemd is not creating the user session for the remote desktop user (this means that /run/user/ is not created).

Before login to the first login after a reboot:

# loginctl
   SESSION        UID USER             SEAT            
        27       1000 administrador                    
        c1        108 lightdm          seat0

2 sessions listed.
# ls /run/user
1000  108
# ps ax | grep xrdp-sesman
12598 ?        S      0:00 /usr/sbin/xrdp-sesman

After a connection with a RD user (m004786):

# loginctl 
   SESSION        UID USER             SEAT            
        27       1000 administrador                    
        c1        108 lightdm          seat0           
        c8   10059353 m004786                          

3 sessions listed.
# ls /run/user
1000  10059353  108
# ps ax | grep xrdp-sesman
12598 ?        S      0:00 /usr/sbin/xrdp-sesman
14028 ?        S      0:00 /usr/sbin/xrdp-sesman
# loginctl session-status c8
c8 - m004786 (10059353)
           Since: Thu 2017-06-15 12:51:21 CEST; 1min 9s ago
          Leader: 12598 (xrdp-sesman)
         Display: :18
         Service: xrdp-sesman; type x11; class user
           State: active
            Unit: session-c8.scope
                  ├─12598 /usr/sbin/xrdp-sesman
                  ├─14028 /usr/sbin/xrdp-sesman
                  ├─14029 x-session-manager
[...]

Note that there are two xrdp-sesman processes inside the session.

After loggin off:

# loginctl
   SESSION        UID USER             SEAT            
        27       1000 administrador                    
        c1        108 lightdm          seat0           
        c8   10059353 m004786                          

3 sessions listed.
# ls /run/user
1000  10059353  108
# ps ax | grep xrdp-sesman
12598 ?        S      0:00 /usr/sbin/xrdp-sesman
# loginctl session-status c8
c8 - m004786 (10059353)
           Since: Thu 2017-06-15 12:51:21 CEST; 5min ago
          Leader: 12598 (xrdp-sesman)
         Display: :18
         Service: xrdp-sesman; type x11; class user
           State: closing
            Unit: session-c8.scope
                  └─12598 /usr/sbin/xrdp-sesman

Note that the session state is 'closing' and there remains one xrdp-sesman process inside the session (it corresponds to the service, so it will never stop unless the service is restarted).

Now I log in with another user (ge01350):

# loginctl 
   SESSION        UID USER             SEAT            
        27       1000 administrador                    
        c1        108 lightdm          seat0           
        c8   10059353 m004786                          

3 sessions listed.
# ls /run/user
1000  10059353  108
# ps ax | grep xrdp-sesman
12598 ?        S      0:00 /usr/sbin/xrdp-sesman
17689 ?        S      0:00 /usr/sbin/xrdp-sesman
# loginctl session-status c8
c8 - m004786 (10059353)
           Since: Thu 2017-06-15 12:51:21 CEST; 10min ago
          Leader: 12598 (xrdp-sesman)
         Display: :18
         Service: xrdp-sesman; type x11; class user
           State: closing
            Unit: session-c8.scope
                  ├─12598 /usr/sbin/xrdp-sesman
                  ├─17689 /usr/sbin/xrdp-sesman
                  ├─17690 x-session-manager
[...]

It has not created the session for the new user and its state is still 'closing', however the session manager is running with the new user:

# ps axu | grep x-session-manager
ge01350  17690  0.0  0.4 375372 16580 ?        Sl   13:00   0:00 x-session-manager

If I close the session and restart the xrdp-sesman service, the session is finally closed. After that, if I log in again with ge01350, the /run/user/ directory is created normally.

If I log the two users simultaneously, they share the same systemd session.

The users come from an Active Directory using winbind and pam. An ssh session works fine, so I don't think this could be the reason.

I've been looking at the configuration but I don't see anything that could be related.

[geiseri]

Something is strange with systemd interaction. I am noticing on Arch Linux that I can log in just fine, but when I log out the session is stuck in a "closing" state. From then on I cannot get a new session, but the desktop starts (at least things that don't need dbus or a usable systemd session). I think the problem is in session.c on how the sesman process forks. I noticed in the systemd-cgls command BOTH xrdp-sesman processes are in the session scope. In theory only the child should be in the session scope. This may actually be the problem, because if systemd kills the session on "logout" then xrdp-sesman terminates the parent process. I need to look into this more though. Do you see a full cleanup of processes on logout?

[xhernandez]

No. As you can see in my first message, after closing the session, an xrdp-sesman process remains open but it's the service itself, so it cannot be closed. The systemd user session is kept in the closing state and all following rdp connections reuse the same session.

[geiseri]

If you check the loginctl show-session cX what PID is the group leader? On mine it is the system wide xrdp-sesman. If I kill that the session finishes closing. Sadly that means I have killed all other users session :) Now on my system a reconnect tries to use the old session, but for one reason or another its in a screwed up state. This causes me to have to restart the sesman servere anyway. I wonder if the problem is that xrdp-sesman forks two children (the xserver and then the desktop session) and that in turn causes systemd to think that is the group leader for the session.

[geiseri]

It looks like the code there forks correctly on pstree, but in systemd-cgls both xrdp-sesman PIDs are in the session scope. I think this is because the login for the session is somehow getting created in the parent so it is moved into the user scope. I am having problems following the code to see what forks what, but I think what needs to happen is:

1. Fork sesman child
2. Auth the user and open the session
3. Fork off X from sesman child
4. Fork off startwm.sh from sesman child

Is that in fact what is happening now? The way I am following the code is as follows:

1. Auth the user and open the session
2. Fork sesman child
3. Fork off X from sesman child
4. Fork off startwm.sh from sesman child

@jsorg71 or @metalefty it looks like you guys authored the code, can you comment on this?

[jsorg71]

@geiseri Yes, you are right, that is how it works now.
The main process needs to keep a list of session info for reconnect, that is the main reason auth and open in done in main process. We'll need to change the design a bit.

[geiseri]

Yeah, I see sesman/session.c line 460 will create the systemd session. This will cause the parent to become part of the user's scope. Now in theory its a matter of moving auth_start_session(...) into the child process we should be fine. The question is what of the first data argument is used because the parent would not have access to that without some sort of RPC or some sort of session file.

[geiseri]

I did confirm that moving lien 460 to line 469 does correctly behave, but I am not sure what that means for people not using systemd + pam. I tested and login/logout behaves correctly, and i could disconnect and reconnect again from Xorg. I need to test VNC and X11rdp yet, but it looks encouraging.

[metalefty]

This issue should be solved by #806.

[geiseri]

It looks fixed from my testing, @xhernandez can you please also confirm?

[xhernandez]

@geiseri, @metalefty sorry for the late answer. I've been unable to test it earlier. It's working fine now. Thanks for your help.

[usul0184]

Apologies if I'm totally off-base (complete newbie here), but I found this old issue and I wonder if something similar is happening in the latest xrdp 0.9.14. I'm running it on Manjaro 18.0 XFCE Edition. When I reboot my server, connect to it via xrdp, and run loginctl, I literally do not see a session for xrdp-sesman. This is the case whether I have nothing in startwm.sh except for exec xterm or whether I bring up Xfce and everything else. Again, complete newbie here, so maybe this is a problem with pam or something, but I thought I would raise it here. Thanks!

[matt335672]

Hi @usul0184

There are no changes in this area on our side that I'm aware of.

You'll get a new session when you log in if both the following are true (I think):-

• xrdp-sesman is not already running in a session
• /etc/pam.d/xrdp-sesman contains (at some depth) session xxx pam_systemd.so

The first of these is quite important. For example, if you run xrdp-sesman interactively, maybe to debug something, you won't get another session for the login. Instead you'll get a message like the following in the system log:-

pam_systemd(xrdp-sesman:session): Cannot create session: Already running in a session

I don't have a copy of Manjaro to hand at the moment, but I've verified the above with v0.9.14 on Ubuntu 18.04.

Hope that helps,

[usul0184]

Thanks! Actually, I think the problem is the same as #1677.