Date: Wed, 21 Nov 2001 16:40:05 -0800 (PST) From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/24955:/usr/bin/tail -F in 4.1+ doesn't work if file inode changes (works in 4.0) Message-ID: <200111220040.fAM0e5T26465@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/24955; it has been noted by GNATS.
From: Ian Dowse <iedowse@maths.tcd.ie>
To: Maxim Konovalov <maxim@macomnet.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/24955:/usr/bin/tail -F in 4.1+ doesn't work if file inode changes (works in 4.0)
Date: Thu, 22 Nov 2001 00:39:28 +0000
In message <20011122002632.O38176-100000@news1.macomnet.ru>, Maxim Konovalov wr
ites:
>
>Looks OK for me except one minor problem, see below
Yes, I expect there are still a few rough edges :-)
>> case USE_SLEEP:
>> (void) usleep(250000);
>> clearerr(fp);
>+ if (kq != -1)
>+ action = ADD_EVENTS;
>
>It will help to break USE_SLEEP cycle when you remove symlink to fname
>and recreate it again. Of course it will break automatically when new
>data arrives but it may never happen.
True, I think I noticed this problem also. I originally had it
continuing to use kqueue while it was waiting for the file to
reappear (i.e. there was no "else action = USE_SLEEP" for the failed
stat case), but I was worried that in some cases the kevent() loop
might spin where the file had really gone away (e.g NFS, forcibly
unmounted filesystem etc). I guess another option would be to add
a while loop around the stat() containing a sleep(), e.g
if (Fflag && ...) {
while (stat(...) != 0)
sleep(1);
if (sb2.st_ino != sbp->st_ino || ...) {
... freopen(...);
action = ADD_EVENTS;
}
}
That would avoid a potential kevent() spin loop, and revert to the
nicer situation where `action' can only change between sleep and
kqueue via the ADD_EVENTS code. Any better suggestions welcome!
I noticed, BTW, that tail -F doesn't work reliably on NFS (I assume
it never did, and it is hard to fix). The problem is that stat()
can succeed even after the file has been deleted due to cacheing,
but as soon as you try to read, ESTALE is returned, so tail just
exits with an error.
Ian
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?200111220040.fAM0e5T26465>