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