I did truss on two servers. Here's the output. Unfortunately, they both
match the sample you gave me - they open and write to things without an
error.
This is on server Telnet. The problem doesn't appear here. A user logged
in via SSH shows up in the 'w' listing.
17945: open("/var/adm/utmpx", O_RDWR|O_CREAT, 0644) = 5
17945: open("/var/adm/utmpx", O_RDWR) = 6
17945: access("/var/adm/utmp", 0) = 0
17945: fstat64(6, 0xEFFFEDC0) = 0
17945: ioctl(6, TCGETA, 0xEFFFED4C) Err#25 ENOTTY
17945: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 5580
17945: read(6, 0x000E521C, 8192) = 0
17945: getuid() = 0 [0]
17945: lseek(5, 0, SEEK_SET) = 0
17945: lseek(6, 0, SEEK_SET) = 0
17945: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 5580
17945: lseek(6, 0xFFFFF8BC, SEEK_CUR) = 3720
17945: llseek(6, 0, SEEK_CUR) = 3720
17945: write(6, " g r e g o r\0\0\0\0\0\0".., 372) = 372
17945: open("/var/adm/utmp", O_RDWR|O_CREAT, 0644) = 7
17945: lseek(7, 360, SEEK_SET) = 360
17945: write(7, " g r e g o r\0\0\0\0\0\0".., 36) = 36
17945: close(7) = 0
17945: open("/etc/utmppipe", O_RDWR|O_NDELAY|O_NONBLOCK) = 7
17945: write(7, "\0\0\001\0\0 F !", 8) = 8
17945: close(7) = 0
17945: open("/var/adm/wtmp", O_WRONLY|O_APPEND) = 7
17945: open("/var/adm/wtmpx", O_WRONLY|O_APPEND) = 8
17945: lseek(7, 0, SEEK_END) = 7226892
17945: lseek(8, 0, SEEK_END) = 0x047A3CCC
17953: Received signal #20, SIGWINCH [default]
17945: write(7, " g r e g o r\0\0\0\0\0\0".., 36) = 36
17945: write(8, " g r e g o r\0\0\0\0\0\0".., 372) = 372
17945: close(7) = 0
17945: close(8) = 0
17945: close(5) = 0
17945: llseek(6, 0, SEEK_CUR) = 4092
17945: close(6) = 0
Here's the truss output for server Home. On Home, a user logged in via SSH
does not appear in 'w' listings.
9462: open("/var/adm/utmpx", O_RDWR|O_CREAT, 0644) = 5
9462: open("/var/adm/utmpx", O_RDWR) = 6
9462: access("/var/adm/utmp", 0) = 0
9462: fstat64(6, 0xEFFFECA8) = 0
9462: ioctl(6, TCGETA, 0xEFFFEC34) Err#25 ENOTTY
9462: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
9462: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 1852
9462: read(6, 0x000E6014, 8192) = 0
9462: getuid() = 0 [0]
9462: lseek(5, 0, SEEK_SET) = 0
9462: lseek(6, 0, SEEK_SET) = 0
9462: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 8192
9462: read(6, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192) = 1852
9462: lseek(6, 0xFFFFFE8C, SEEK_CUR) = 9672
9462: llseek(6, 0, SEEK_CUR) = 9672
9462: write(6, " g r e g o r\0\0\0\0\0\0".., 372) = 372
9462: open("/var/adm/utmp", O_RDWR|O_CREAT, 0644) = 7
9462: lseek(7, 936, SEEK_SET) = 936
9462: write(7, " g r e g o r\0\0\0\0\0\0".., 36) = 36
9462: close(7) = 0
9462: open("/etc/utmppipe", O_RDWR|O_NDELAY|O_NONBLOCK) = 7
9462: write(7, "\0\0\001\0\0 %\t", 8) = 8
9462: close(7) = 0
9462: open("/var/adm/wtmp", O_WRONLY|O_APPEND) = 7
9462: open("/var/adm/wtmpx", O_WRONLY|O_APPEND) = 8
9462: lseek(7, 0, SEEK_END) = 7849980
9462: lseek(8, 0, SEEK_END) = 0x04D5BA44
9462: write(7, " g r e g o r\0\0\0\0\0\0".., 36) = 36
9462: write(8, " g r e g o r\0\0\0\0\0\0".., 372) = 372
9462: close(7) = 0
9462: close(8) = 0
9462: close(5) = 0
9462: llseek(6, 0, SEEK_CUR) = 10044
9462: close(6) = 0
Here are the permissions of various files. No diffs between the two
servers.
HOME
-rw-r--r-- 1 root bin 972 Aug 11 19:22 utmp
-rw-r--r-- 1 root bin 10044 Aug 11 19:22 utmpx
-rw-rw-r-- 1 adm adm 7850376 Aug 11 19:22 wtmp
-rw-rw-r-- 1 adm adm 81119808 Aug 11 19:22 wtmpx
prw------- 1 root root 0 Aug 11 19:22 /etc/utmppipe
-r-sr-xr-x 2 root bin 11848 Jul 15 1997 /bin/w
TELNET
-rw-r--r-- 1 root bin 540 Aug 11 19:22 utmp
-rw-r--r-- 1 root bin 5580 Aug 11 19:22 utmpx
-rw-rw-r-- 1 adm adm 7227432 Aug 11 19:22 wtmp
-rw-rw-r-- 1 adm adm 75125400 Aug 11 19:22 wtmpx
prw------- 1 root root 0 Aug 11 19:22 /etc/utmppipe
-r-sr-xr-x 2 root bin 11848 Jul 15 1997 /bin/w
It may be of interest that users on our system have their shell set to a
menu instead of a normal UNIX shell. The menus are written in PERL and
compiled with perlcc. The menus themselves are pretty simple and don't
have any code for handling login accounting, etc. When the 'w' is run,
it's from a menu option that does a system() call to open a Bourne shell.
So I changed my shell to /bin/sh instead of the menu. Then I noticed
someting really weird.
These three snapshots are taken a) logged in via telnet on pts/4, b) when
a 2nd session logs in via SSH on pts/6, and c) when the SSH session logs
out, with the telnet session still connected. It looks like the SSH
session "overwrote" my previous login session, perhaps?
root@home# w
7:34pm up 13 day(s), 7:36, 4 users, load average: 4.22, 3.17, 3.14
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:10 4 1 /bin/pine
adam.ols pts/2 Mon 6pm 2days -adminsh
gregor pts/4 7:29pm 10 w
root@home# w
7:35pm up 13 day(s), 7:36, 4 users, load average: 4.25, 3.25, 3.16
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:10 4 1 /bin/pine
adam.ols pts/2 Mon 6pm 2days -adminsh
gregor pts/6 7:34pm -sh
root@home# w
7:35pm up 13 day(s), 7:36, 3 users, load average: 3.94, 3.21, 3.15
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:10 4 1 /bin/pine
adam.ols pts/2 Mon 6pm 2days -adminsh
Here, I logged in via SSH (on pts/4) and this time I was in the 'w'
listing. I logged in via telnet twice on pts/5 and pts/6. I open a second
SSH session and pts/7 shows up, but my pts/4 session vanishes. During all
of these sessions except the one pn pts/4, I sat idle - didn't use any
menu options, didn't shell out from the menu, nothing. All the activity
was done via the telnet session on pts/4.
root@home# w
7:50pm up 13 day(s), 7:51, 5 users, load average: 4.29, 3.61, 3.31
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:25 4 1 /bin/pine
gregor pts/5 7:49pm 4 w
adam.ols pts/2 Mon 6pm 2days -adminsh
gregor pts/4 7:48pm 1 -adminsh
root@home# w
7:50pm up 13 day(s), 7:52, 6 users, load average: 5.40, 3.92, 3.42
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:25 4 1 /bin/pine
gregor pts/5 7:49pm 4 w
adam.ols pts/2 Mon 6pm 2days -adminsh
gregor pts/6 7:50pm -adminsh
gregor pts/4 7:48pm 2 -adminsh
root@home# w
7:51pm up 13 day(s), 7:52, 6 users, load average: 6.94, 4.54, 3.66
User tty login@ idle JCPU PCPU what
adamo pts/0 Thu 7pm 6days -adminsh
polson pts/12 6:21pm 1:26 4 1 /bin/pine
gregor pts/5 7:49pm 4 w
adam.ols pts/2 Mon 6pm 2days -adminsh
gregor pts/6 7:50pm 1 -adminsh
gregor pts/7 7:51pm -adminsh
This is unlike my usual mode of logging in, where I use SSH exclusively
and access a shell from inside the menu. In the usual case, only my
current session (e.g. the one running 'w') shows up.
In my novice opinion, it looks like SSH is overwriting my utmp entries.
Any ideas if this is what's really happening or how to fix this?
Thanks.
--
Gregor Mosheh
[EMAIL PROTECTED]
On-Site Systems Admin, Humboldt Internet
707.825.4638
On Thu, 12 Aug 1999, Pauline van Winsen wrote:
> hi gregor/pam,
>
> > Turns out that 'w' uses the utmp file. Also turns out that sshd makes a
> > utmp entry just fine (see lib/sshsession/wtmp.c). So the theory put forth
> > by one of our sysadmins that sshd wasn't making a wtmp/wtmpx/utmp entry
> > isn't the case.
>
> hmmm. what does a truss of sshd on the server side show when users login with ssh?
> # /usr/bin/truss -a -f -p `cat /path/to/sshd_pid_file` -o /tmp/truss_output
>
> i see the following in the truss output when sshd gets to adding
> utmp entries. i.e. no errors returned from the open or write calls.
> 'w' output looks fine.
>
> 1111: open("/var/adm/utmp", O_RDWR|O_CREAT, 0644) = 5
> 1111: lseek(5, 288, SEEK_SET) = 288
> 1111: write(5, " a d m i n\0\0\0 P 0 0 1".., 36) = 36
> 1111: close(5) = 0
> 1111: fcntl(3, F_SETLK, 0xEFFFF0EC) = 0
> 1111: open("/etc/utmppipe", O_RDWR|O_NDELAY|O_NONBLOCK) = 5
> 1111: write(5, "\0\0\001\0\004 W", 8) = 8
> 1111: close(5) = 0
> 1111: open("/var/adm/wtmp", O_WRONLY|O_APPEND) = 5
> 1111: open("/var/adm/wtmpx", O_WRONLY|O_APPEND) = 7
> 1111: lseek(5, 0, SEEK_END) = 140472
> 1111: lseek(7, 0, SEEK_END) = 1451408
> 1111: write(5, " a d m i n\0\0\0 P 0 0 1".., 36) = 36
> 1111: write(7, " a d m i n\0\0\0\0\0\0\0".., 372) = 372
> 1111: close(5) = 0
> 1111: close(7) = 0
>
> i'd also look for differences between permissions on /var/adm/*tmp*
> & the 'w' command itself & check that /usr/lib/utmpd is running.
> i don't see this problem with ssh under 2.5.1, 2.6 or 2.7.
>
> hope this helps,
> pauline
>
