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
