From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Eggert Subject: bug#21460: Race condition in tests/tail-2/assert.sh Date: Fri, 11 Sep 2015 10:18:36 -0700 Message-ID: <55F30CEC.7060102@cs.ucla.edu> References: <87wpvw2ad8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87wpvw2ad8.fsf@gnu.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-coreutils-bounces+gcgcb-bug-coreutils-616=gmane.org@gnu.org Sender: bug-coreutils-bounces+gcgcb-bug-coreutils-616=gmane.org@gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , 21460@debbugs.gnu.org Cc: bug-guix@gnu.org List-Id: bug-guix.gnu.org Ludovic Court=C3=A8s wrote: > I think the problem happens when =E2=80=98tail=E2=80=99 opens =E2=80=98= foo=E2=80=99 right in between of > the two notifications: =E2=80=98foo=E2=80=99 is still there, and so =E2= =80=98tail=E2=80=99 doesn=E2=80=99t > report anything. > > Does that make sense? Yes, though if the link count is indeed zero, I'm surprised that 'tail' c= an open=20 the file -- that sounds like a bug in the kernel. If there is such a kernel bug and 'tail' can open a file with a link coun= t of=20 zero, that would explain why 'tail' does not immediately receive an=20 IN_DELETE_SELF notification: after all, the file is open (by 'tail' itsel= f) so=20 it should not be deleted even if it has a link count of zero. If so, it = appears=20 that there's another kernel bug later: when 'tail' closes the file's last= file=20 descriptor, the file should be deleted and an IN_DELETE_SELF notification= should=20 be sent to 'tail'.