Found the lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521

Looking forward to a followup talk of him gloating now this bug has been reported

I genuinely doubt he'll notice.

Bryan, if you're reading this, it's merely because I doubt that you actually check Linux bugtrackers.

Also, GNU tail provides tail -F, which does what you want tail -f to do. There is a reason for this. I don't remember what it is, but I think the manpage talks about it.

-F vs -f: -F figures out the new inode if the file is deleted (*notify are inode-based, if you see DELETE_SELF for a file you'll never get any more events)

...which actually does handle truncation properly. For some reason.

It's because IN_MODIFY covers both writing and truncation, so the code path for such an event has to handle both anyway.

Ironically, given that you mention M. Cantrill, GNU tail does not really handle truncation properly, and gives up for almost the very case that M. Cantrill did: when the truncation doesn't decrease the size, or is very closely followed by a write that ends up not decreasing the size.

Of course, truncation is not the best way to organize writing log files in the first place. daemontools family style log management (in cyclog, multilog, et al.) starts a fresh file whenever there is a rotation, so these problems of truncation never arise.

What I was actually referring to was Cantrill's talk about tail -f on Solaris, and how he improved it (so that it at least handled some cases). He looked at the GNU behavior, and determined that truncation was noted, but nothing was done about it. This is true if you use -f. However, if you use -F, truncation is handled properly.

I know what you were referring to. It has already been hyperlinked; I had already referred to where M. Cantrill explained that he gave up; and as I have just explained, the people who wrote GNU tail gave up in the same way (for much the same reasons, I expect) and GNU tail does not handle truncation any more properly than M. Cantrill did. There's no doco, but there's commentary in the code observing the problem.

And as I then went on to explain, this whole idea of truncating one log file over and over is a poor one, and not the best way to do logging in the first place. So the fact that both M. Cantrill and the GNU people gave up should perhaps be viewed as stopping when an inferior mechanism is pushed beyond its limits.

Naturally. This is quite sensible.

The ambiguities of language sometimes make two people with the same idea think their ideas are different.

I don't think you need madvise() for this bug. It's just easier to exploit that way.