Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Sep 2000 19:20:03 -0700 (PDT)
From:      Gerhard Sittig <Gerhard.Sittig@gmx.net>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/21017: mtree's "no such file" message at job's end
Message-ID:  <200009070220.TAA18476@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/21017; it has been noted by GNATS.

From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Sheldon Hearn <sheldonh@uunet.co.za>
Subject: Re: bin/21017: mtree's "no such file" message at job's end
Date: Wed, 6 Sep 2000 22:26:08 +0200

 On Tue, Sep 05, 2000 at 18:28 +0200, Gerhard Sittig wrote:
 > 
 > [ ... ]  I hope to have the stderr tail of truss available,
 > then.  Maybe I can tell you soon which syscall results in the
 > ENOENT(?) error.
 
 truss(1)ing mtree is what happened now.  The result of
 
   KEYS=nlink,type,mode,flags,uid,gid,size,time,cksum,md5digest,sha1digest,ripemd160digest
   truss /usr/sbin/mtree -K $KEYS -p /usr -x -X $DBDIR/_usr.ex < $DBDIR/_usr.db 2>&1 >/dev/null | tail -500
 
 looks like this
 
 ----- truss mtree | tail snippets -------------------------------
 ...
 open("./compat/linux/usr/lib/libz.so.1",0,027757774510) = 3 (0x3)
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 ...
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 read(0x3,0xbfbff548,0x400)			 = 421 (0x1a5)
 read(0x3,0xbfbff548,0x400)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 open("./compat/linux/usr/lib/libz.so.1",0,027757774510) = 3 (0x3)
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 ...
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 read(0x3,0xbfbff548,0x400)			 = 421 (0x1a5)
 read(0x3,0xbfbff548,0x400)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 open("./compat/linux/usr/lib/libz.so.1.1.3",0,00) = 3 (0x3)
 read(0x3,0xbfbfb948,0x4000)			 = 16384 (0x4000)
 read(0x3,0xbfbfb948,0x4000)			 = 16384 (0x4000)
 read(0x3,0xbfbfb948,0x4000)			 = 16384 (0x4000)
 read(0x3,0xbfbfb948,0x4000)			 = 13733 (0x35a5)
 read(0x3,0xbfbfb948,0x4000)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 open("./compat/linux/usr/lib/libz.so.1.1.3",0,027757774510) = 3 (0x3)
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 ...
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 read(0x3,0xbfbff548,0x400)			 = 421 (0x1a5)
 read(0x3,0xbfbff548,0x400)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 open("./compat/linux/usr/lib/libz.so.1.1.3",0,027757774510) = 3 (0x3)
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 ...
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 read(0x3,0xbfbff548,0x400)			 = 421 (0x1a5)
 read(0x3,0xbfbff548,0x400)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 ...
 open("./compat/linux/usr/lib/python1.5/site-packages/rpmmodule.so",0,027757774510) = 3 (0x3)
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 ...
 read(0x3,0xbfbff548,0x400)			 = 1024 (0x400)
 read(0x3,0xbfbff548,0x400)			 = 168 (0xa8)
 read(0x3,0xbfbff548,0x400)			 = 0 (0x0)
 close(3)					 = 0 (0x0)
 readlink("X11",0x804ef00,1023)			 ERR#2 'No such file or directory'
 mtree: write(2,0xbfbff1b4,7)				 = 7 (0x7)
 line 1361949: X11write(2,0xbfbff1e4,17)				 = 17 (0x11)
 : write(2,0xbfbff1a4,2)				 = 2 (0x2)
 No such file or directory
 write(2,0xbfbff1a4,26)				 = 26 (0x1a)
 sigprocmask(0x1,0x280605a0,0xbfbff84c)		 = 0 (0x0)
 sigprocmask(0x3,0x280605b0,0x0)			 = 0 (0x0)
 write(1,0xd2da000,958)				 = 958 (0x3be)
 exit(0x1)					process exit, rval = 256
 ----- truss mtree | tail snippets -------------------------------
 
 Whoops!  Why is libz.so.1.1.3 being read in chunks of 16KB when
 every other file is read in single KB buffers?  This "finding"
 was done by chance ...  There's no (obvious) reference to read in
 usr.sbin/mtree/*.[ch], so I would expect it to be called from
 {MD5,SHA1_,RIPEMD160_}File(3).
 
 The symlink /usr/compat/linux/usr/lib/X11 seems to cause the
 error.  The db description looks like this:
 
 ----- _usr.db snippet for the symlink ---------------------------
 ...
 # ./compat/linux/usr/lib
 /set type=file uid=0 gid=0 mode=0755 nlink=1
 lib             type=dir nlink=8 size=1536 time=964377066.0
     X11         type=link size=16 time=964377066.0 link=../X11R6/lib/X11
     libbfd-2.9.1.0.24.so \
 ...
 ----- _usr.db snippet for the symlink ---------------------------
 
 The symlink is there but "broken".  This should never hurt mtree,
 neither when creating nor when comparing the database.
 
 ----- ls -l output ----------------------------------------------
 lrwxr-xr-x  1 root  wheel  16 Jul 23 20:31 /usr/compat/linux/usr/lib/X11@ -> ../X11R6/lib/X11
 ls: /usr/compat/linux/usr/X11R6/lib/X11: No such file or directory
 ----- ls -l output ----------------------------------------------
 
 So I ctag(1)ed /usr/src/usr.sbin/mtree, read manpages for
 readlink(2), symlink(7) and fts(3) and tried building and
 checking a database for the /usr/compat/linux path only -- this
 time everything worked!  Well that's a surprise. (Now I can see
 why you wish for a better way to cause the symptom ...)
 
 The only thing I could see is that the above mentioned "X11" file
 is the only broken symlink on the /usr filesystem (that's what I
 get from "find /usr -xdev -type l -print0 | xargs -0 file | grep
 broken", although symlinks aren't necessarily a problem -- perl
 has a lot of these).  And why does this broken symlink break
 readlink(2) sometimes and sometimes it does not?
 
 The only readlink(2) reference I can see in mtree is in the
 rlink() function in compare.c -- but of course I miss all the
 implicit invocations libc or fts(3) could bring with them.  But
 the code makes me quite sure:  errors in readlink cause err(3) to
 be called with the formerly mentioned "line %d: %s" message with
 lineno and fname.  Does it matter that lineno is always _behind_
 the last db line?  I'll dig into this place a little further ...
 
 
 I'm really confused as to where to continue searching, but I'm
 willing to help with whatever I can do ...
 
 To summarize:  It's not about the broken symlink in itself.  But
 readlink(2) fails at a broken symlink when something else
 happened before -- but I don't know what this is. :<  Could
 bin/4961 (nonzero errno although there's no error) apply in this
 case?
 
 
 virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
 Gerhard Sittig   true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
 -- 
      If you don't understand or are scared by any of the above
              ask your parents or an adult to help you.
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009070220.TAA18476>