Today's CVS trouble (HP-UX 10.20)
Lutz Jaenicke
Lutz.Jaenicke at aet.TU-Cottbus.DE
Wed Sep 26 06:12:13 EST 2001
On Tue, Sep 25, 2001 at 05:47:46PM +0200, Lutz Jaenicke wrote:
> On Tue, Sep 25, 2001 at 03:18:48PM +0200, Lutz Jaenicke wrote:
> > That was also my impression. I had a look into loginrec.c and could not
> > see any particular reason.
> > while (!found) {
> > if (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) {
> > log("wtmp_get_entry: read of %s failed: %s",
> > WTMP_FILE, strerror(errno));
> > close (fd);
> > return 0;
> > }
Some further analysis:
Sep 25 18:16:23 ws01 sshd[29512]: wtmp_get_entry: read of /var/adm/wtmp failed:
Bad file number, result=0 (sizeof(ut)=60, fd=3) attempt=1, distance=0, offset=569280
The atomicio() already fails in the first round (attempt=1), so the problem
must be located earlier in the code. Just above the offending loop there
is (slightly modified for testing):
/* Seek to the start of the last struct utmp */
distance = lseek(fd, (off_t)(0 - sizeof(struct utmp)), SEEK_END);
if (distance == -1) {
/* Looks like we've got a fresh wtmp file */
close(fd);
return 0;
}
As you can see from the log excerpt above, "distance=0", so the lseek()
already seems to be suspicious. The only candidate in the lseek() must be
the distance, (as fd and SEEK_END do not offer anything), so I included
a printout of the "(off_t)(0 - sizeof(struct utmp))" into the logging:
if (result != sizeof(ut)) {
log("wtmp_get_entry: read of %s failed: %s, result=%d (sizeof(ut)=%d, fd=%d) attempt=%d, distance=%d, offset=%d",
WTMP_FILE, strerror(errno), result, sizeof(ut), fd,
counter, distance, (off_t)(0-sizeof(struct utmp)));
Printing off_t with %d looks fishy, and the printed result (569280) does not
look nice, so the printout in the logfile is not that trustworthy.
Based on this printout I had a look into HP-UX header files and found, that
off_t is defined differently with LARGEFILE support, which directly falls
together with the point, that the problem just appeared with today's CVS:
20010925
- (djm) Add AC_SYS_LARGEFILE configure test
...
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGE_FILES value needed for large files... no
...
After removing AC_SYS_LARGEFILE from configure.in, the problem disappears.
I do use 2.52, if that matters...
Best regards,
Lutz
--
Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
More information about the openssh-unix-dev
mailing list