Bug 25066

Summary: xdm-1.1.9: sessreg+who not working; Xstartup should exec sessreg
Product: xorg Reporter: Johannes Dewender <xorg>
Component: App/xdmAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium Keywords: patch
Version: 7.5 (2009.10)   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
fix: exec sessreg, rathern than just running it in Xstartup
none
Patch: Exec sessreg in Xstartup none

Description Johannes Dewender 2009-11-12 19:18:55 UTC 
xdm should register an entry in utmp in order to make a later "who" show that some user is logged in.
However, after the login is complete, there is no such entry.

/etc/X11/xdm/Xstartup has:
/usr/bin/sessreg  -a -w /var/log/wtmp -u /var/run/utmp  -x /etc/X11/xdm/Xservers -l $DISPLAY -h "" $USER

However, utmp saves the pid of the calling process as the session leader. When this session leader is gone, "who" is not showing the session anymore. So it is not there anymore.
But Xstartup is called rather than sourced, so the process with this pid is gone before the user can do anything at all:

output of ps (cut):
root     12349 12340  0 03:49 ?        00:00:00 /bin/sh /etc/X11/xdm/haljo/Xstartup
root     12340 12335  0 03:49 ?        00:00:00 -:0

output of utmpdump /var/run/utmp (cut):
[7] [12349] [:0  ] [jonnyjd ] [:0          ] [haljo               ] [0.0.0.0        ] [Fri Nov 13 03:49:11 2009 CET]

So in order for this to work /etc/X11/xdm/Xstartup needs to get sourced by xdm (here it is pid 12340 that could do this)
As a side effect: the session is destroyed automagically when "-:0" (pid 12340) is closed.

I have no clue if this worked before. It never worked for me and today I took the time to find out why this is exactly.


I am using Arch Linux with
2.6.31.6 kernel
coreutils 7.6 (including who)
sysvinit 2.86 (including utmpdmp)
Comment 1 Johannes Dewender 2009-11-12 19:32:41 UTC 
I also did some further testing on how it should work.
I open a terminal.
who
shows nothing
then:
sudo /usr/bin/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x /etc/X11/xdm/Xservers -l :0 -h haljo jonnyjd
who shows a session for jonnyjd.

Then when I close that terminal and do "who" in a new terminal I don't get anything anymore.

from man utmp:
           struct utmp {
               short   ut_type;              /* Type of record */
               pid_t   ut_pid;               /* PID of login process */
...
When  init(8)  finds  that a process has exited, it locates its utmp entry by ut_pid, sets ut_type to DEAD_PROCESS, and clears  ut_user,  ut_host  and  ut_time with null bytes.

The above mentioned procedure might not be up to date, because nothing is reset. It's just not used anymore when ut_pid doesn exist.


I use glibc 2.11. That might have an impact on the usage of utmp.
Comment 2 Johannes Dewender 2009-11-13 05:04:16 UTC 
Created attachment 31165 [details] [review]
fix: exec sessreg, rathern than just running it in Xstartup

Okay, I read a bit in the code and I think doing it the other way around would be easier:
In stead of sourcing Xstartup you can also "exec" sessreg.

I made a quick patch for the default configuration. Everybody can change the configuration, of course, but it would help a lot if the default configuration is already working.
Comment 3 Johannes Dewender 2009-11-13 12:57:07 UTC 
Created attachment 31184 [details] [review]
Patch: Exec sessreg in Xstartup

Redid the patch with git. Including summary and signed-of.
Comment 4 Julien Cristau 2010-03-09 07:26:45 UTC 
Patch in attachment #31184 [details] [review] seems sane to me.  AFAICT the Xstartup script we're shipping in Debian does that already, and who tells me:
julien   :0           Mar  9 12:28

So, Acked-by: Julien Cristau <jcristau@debian.org>

(updating bug description accordingly)
Comment 5 Alan Coopersmith 2010-03-16 08:43:53 UTC 
Makes sense  - pushed to git master.   Thanks for the patch.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.