coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unexpected behavior of 'tail --follow=name' on special file via syml


From: Glenn Golden
Subject: Re: Unexpected behavior of 'tail --follow=name' on special file via symlink
Date: Wed, 1 Feb 2023 07:46:55 -0700

Pádraig Brady <P@draigBrady.com> [2023-01-31 21:47:43 +0000]:
> On 31/01/2023 19:48, Glenn Golden wrote:
> > Thanks, Pádraig.
> > 
> > With the above patch (applied manually to coreutils 9.1 sources) the
> > 'illegal seek' no longer occurs, but it also doesn't follow the new file:
> > There is no output at all after tail announces that it is "following new 
> > file."
> > 
> > I did verify that the "new" instance of /dev/ttyMYDEV, when observed from
> > another independent process (via cat, less, more, tail, etc.) is indeed
> > sinking output from the device, as expected. But tail just isn't seeing it.
> > 
> > Also fiddled about with --sleep-interval=N (with several values of N) and
> > --retry as well, but no joy.
> 
> The output from `strace tail ...` would be useful I think to help diagnose.
> 

Strace output attached, obtained via

    $ strace -tt --decode-fds=dev,path  \
          tail_p1 --follow=name --lines=+0 /dev/ttyPSLOG 2> strace1.out

where "tail_p1" is the patched 9.1 executable (your patch from the other day).

Note that there's an interesting bit of headscratch on line 199, just after
issuance of the "following new file" message. Looks like strace itself may
have overwritten its own buffer or something. 

I ran strace several times, invoking it exactly as shown above, just to see
if that little feature was present each time, and it is.  I have no clue what
that is due to, or what strace output (if any) may have been lost there.

- Glenn

Attachment: strace1.out
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]