From owner-freebsd-bugs Sun Sep 3 12:20: 6 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CF8D137B43C for ; Sun, 3 Sep 2000 12:20:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA83963; Sun, 3 Sep 2000 12:20:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 7866737B42C for ; Sun, 3 Sep 2000 12:15:26 -0700 (PDT) Received: (qmail 10168 invoked by uid 0); 3 Sep 2000 19:15:24 -0000 Received: from p3ee2164e.dip.t-dialin.net (HELO speedy.gsinet) (62.226.22.78) by mail.gmx.net with SMTP; 3 Sep 2000 19:15:24 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id VAA07806 for FreeBSD-gnats-submit@freebsd.org; Sun, 3 Sep 2000 21:11:43 +0200 Message-Id: <20000903211143.T252@speedy.gsinet> Date: Sun, 3 Sep 2000 21:11:43 +0200 From: Gerhard Sittig To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/21017: mtree's "no such file" message at job's end Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 21017 >Category: bin >Synopsis: mtree "no such file" message at job's end >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 03 12:20:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Gerhard Sittig >Release: FreeBSD 4.1-STABLE i386 >Organization: in private >Environment: I've seen this on two FreeBSD 4-STABLE systems built in July and on one FreeBSD 4-STABLE system built in August. >Description: mtree -c -K $KEYS | mtree -K $KEYS produces an (IMO) erroneous "no such file" error message for large mtree -c output with a line number one bigger than the database size and a filename which "isn't real". >How-To-Repeat: I built a "tripwire lookalike" script using mtree. The database is generated with the following command: MTREE=/usr/sbin/mtree KEYLIST=nlink,type,mode,flags,uid,gid,size,time,cksum,md5digest,sha1digest,ripemd160digest for FS in / /tmp /var /usr /home; do DB=$DBDIR/`echo $FS | tr '/' '_'` EX=`[ -r $DB.ex ] && echo -X $DB.ex` $MTREE -c -K $KEYLIST -p $FS -x $EX > $DB.db done Checking the fs' content against the database is done via ... $MTREE -K $KEYLIST -p $FS -x $EX < $DB.db ... The checking command's output at the /usr fs is: mtree: line 395022: libtermcap_p.a: No such file or directory "wc _usr.db" output: 395021 929838 21246776 _usr.db "cat _usr.ex" output: ./obj/* This behaviour is repeatable here, works for "small" filesystems and fails at /usr. The other machines list "30_qmail.sh" (an /usr/local/etc/rc.d start script) and "X11" as the "missing" file which makes me say "the filename isn't really searched for or shouldn't be". It's not the last and neither is it the longest name in the list to be checked. Some statistics: stein "uname -a" output: FreeBSD stein.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Mon Jul 31 19:17:22 CEST 2000 root@stein.gsinet:/usr/obj/usr/src/sys/STEIN i386 stein "wc *" output (/usr fails, see above): 3455 10684 203428 _.db 395021 929838 21246776 _usr.db 1 1 8 _usr.ex 756 1741 35231 _var.db organ "uname -a" output: FreeBSD organ.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Tue Aug 29 01:32:17 CEST 2000 root@organ.gsinet:/usr/obj/usr/src/sys/ORGAN i386 organ "wc *" output (/home works! /usr fails): 4328 12284 250597 _.db 505369 1182903 26115651 _home.db 601 1421 36233 _mnt_DOS.db 32 75 670 _tmp.db 1361948 3202398 74490769 _usr.db 1 1 8 _usr.ex 4288 9492 197807 _var.db The third machine is further away and not accessible right now. The error looks quite random and seems to occur when huge data amounts sum up (rare / strange program paths are passed? buffers get overridden?). It's not about fix values, compare stein's /usr against organ's /home (organ has more processing power and way more RAM and this seems to matter). I don't know what's going on when encountering EOF of the database stream and what conditions have to meet to trigger this failure message. >Fix: None known yet, I couldn't even find the problem spot. But you can ask me to watch out for whatever you like -- the error is absolutely reproducable here. 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. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message