> I have a large number of Sparc5s used for a single application. The
> user logs in using xdm and launches the application from his or her
> openwin menu. This is the only thing in that user's openwin menu- in
> particular the user has no shell access.
>
> On some of these machines, when a system administrator connects remotely
> and does a "w" or "who", the user logged in under xdm at the console does
> not show up. Doing a "last" shows that the user was logged in at the console
> for 0 seconds. However, if we grep through the process table, the user is
> running a lot of applications and is quite clearly logged in.
>
> Since it may be important, I should add that we rotate the utmp, utmpx,
> wtmp, and wtmpx files on Saturday morning with the other files that are
> rotated by /usr/lib/newsyslog. There are kill scripts that are run from
> cron, so no user is ever logged in when these files are rotated.
>
> This is causing a problem, because admins think that a machine is idle
> when in fact the user is logged on and trading. I'm looking for a way
> to get last, w, and who to correctly report that the user has logged in
> through xdm and is on the machine. Can anyone give my any suggestions
> for this one? Thanks much.
The solution:
As it turns out this is a known problem in Sun, and they are not going to
fix it because there are a number of workarounds. Here is the whole story.
The XDM startup scripts are called under the control of sessreg, which
is supposed to update the utmp and wtmp files. Starting with Solaris 2.3
the XDM config files are shipped with the correct sessreg lines in place,
so that is not the problem.
The utmp daemon, /usr/lib/utmpd (started from S88utmpd in rc2.d), is a daemon
that goes along and checks to make sure that processes that have exited
have correctly cleaned up the utmp and wtmp files. It is unable to tell
the difference between someone who has logged out and someone who is still
logged in through xdm, so it removes their entries in this file. Thats
why they show as being logged in for less than a minute.
Doing a keyword search on "xdm sessreg utmp" on SunSolve returns these
bug IDs (plus two others not directly relevant), which give workarounds.
bug 1199702 xdm 3.4's call to sessreg in Startup script is immediately
removed by utmpd
bug 4030827 Under sol2.5.1 NO2.6 last command doesn't show any entry of
users who login in
bug 1143011 the wtmp file is not updated if a user logs in by an xlogin
with xdm.
One workaround is to just disable utmpd. This daemon is new to Solaris 2.x,
and isn't really necessary. I have chosen this option, and everything
appears to be running just fine. (The reason this was an intermittent
problem for me was that 66 of my 241 production machines had utmpd running,
and the remaining did not.)
Another supposed workaround is to add "-w /var/adm/wtmp" to the sessreg
command in the GiveConsole and TakeConsole xdm config lines. I tried
this and it corrupted my wtmp file so badly that I had to rebuild the
box. Gee, thanks, Sun. DON'T TRY THIS ONE, FOLKS.
A third workaround is to create an entry in /dev to create a fake tty.
In the TakeConsole script, add
# Make a fake tty for finger, wall ...
if [ ! -r /dev/$DISPLAY ]; then
ln -s /dev/null /dev/$DISPLAY
fi
# Register the login, with XDM as pid
exec sessreg -a -l $DISPLAY $USER
and then in the GiveConsole cleanup script you can remove it. (I've
cut and pasted this directly from SunSolve. Yes, the link is *created*
both times. I think that this one should be a delete, not a link, but
I'm not sure so I'll just copy it verbatim into my summary)
# Remove the login.
sessreg -d -l $DISPLAY -x /usr/openwin/lib/xdm/Xservers $USER
# Clean up the /dev directory
if [ -r /dev/$DISPLAY ]; then
ln -s /dev/null /dev/$DISPLAY
fi
Since in my case all of the users were logging in on the console,
/dev/console already existed and this was not a problem. Users of xdm
on remote xterms may find this useful, though.
Sun is not going to fix this the right way (i.e., recoding sessreg or
xdm itself) because this is not a problem under CDE. Their official
solution therefore is to stop using XDM and move to CDE. Yeah, as if
that was a viable solution at the drop of a hat...
Thanks to
Ronald Loftin <reloftin@mailbox.syr.edu>
Feng Qiu <fqiu@bmb-fs1.biochem.okstate.edu>
Greg Obremski <obremski@alpha.fdu.edu>
Sweth Chandramouli <sweth@astaroth.nit.gwu.edu>
Aleksandar Milivojevic <alex@srce.hr>
djohnson@nbserv2.dseg.ti.com (Danny Johnson)
"Karl E. Vogel" <vogelke@c17mis.region2.wpafb.af.mil>
Christopher L. Barnard Senior Systems Administrator
(312) 347-4901 Information Systems, The Chicago Board of Trade
cbarnard@tsg.cbot.com http://www.cs.uchicago.edu/~cbarnard
PGP public key available via MIT PGP keyserver or on my web page