From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 12:23:44 2015 Received: (at submit) by debbugs.gnu.org; 11 Sep 2015 16:23:44 +0000 Received: from localhost ([127.0.0.1]:57128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaR71-0003dG-Jr for submit@debbugs.gnu.org; Fri, 11 Sep 2015 12:23:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55528) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaR6z-0003d8-Gy for submit@debbugs.gnu.org; Fri, 11 Sep 2015 12:23:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaR6y-0004V6-4D for submit@debbugs.gnu.org; Fri, 11 Sep 2015 12:23:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaR6y-0004V0-0l for submit@debbugs.gnu.org; Fri, 11 Sep 2015 12:23:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaR6w-0006TY-GR for bug-guix@gnu.org; Fri, 11 Sep 2015 12:23:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaR6s-0004TC-Id for bug-guix@gnu.org; Fri, 11 Sep 2015 12:23:38 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaR6s-0004T6-FF; Fri, 11 Sep 2015 12:23:34 -0400 Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:34884 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZaR6r-00009S-QZ; Fri, 11 Sep 2015 12:23:34 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: bug-coreutils@gnu.org Subject: Race condition in tests/tail-2/assert.sh X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 25 Fructidor an 223 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Fri, 11 Sep 2015 18:23:31 +0200 Message-ID: <87wpvw2ad8.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: bug-guix@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Hello, We have observed intermittent failures of tests/tail-2/assert.sh (Coreutils 8.24, libc 2.22), especially showing up on relatively slow machines (armhf and mips64el.) The failure is with =E2=80=98tail --follow=3Dname=E2=80=99, which, in inoti= fy mode, would fail to report that file =E2=80=98foo=E2=80=99 has been deleted. The strace of a correct execution (x86_64) is like this: --8<---------------cut here---------------start------------->8--- lstat("a", {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 lstat("foo", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 inotify_init() =3D 5 write(1, "=3D=3D> a <=3D=3D\nx\n\n=3D=3D> foo <=3D=3D\n", 25) =3D 25 inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) =3D 1 inotify_add_watch(5, "a", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = =3D 2 inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) =3D 1 inotify_add_watch(5, "foo", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF= ) =3D 3 open("a", O_RDONLY|O_NONBLOCK) =3D 6 lstat("a", {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 fstat(6, {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 fstatfs(6, {f_type=3D"EXT2_SUPER_MAGIC", f_bsize=3D4096, f_blocks=3D1673821= 0, f_bfree=3D1219533, f_bavail=3D367617, f_files=3D4259840, f_ffree=3D24064= 92, f_fsid=3D{1622537548, 1497272261}, f_namelen=3D255, f_frsize=3D4096}) = =3D 0 close(6) =3D 0 fstat(3, {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 open("foo", O_RDONLY|O_NONBLOCK) =3D 6 lstat("foo", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstat(6, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstatfs(6, {f_type=3D"EXT2_SUPER_MAGIC", f_bsize=3D4096, f_blocks=3D1673821= 0, f_bfree=3D1219533, f_bavail=3D367617, f_files=3D4259840, f_ffree=3D24064= 92, f_fsid=3D{1622537548, 1497272261}, f_namelen=3D255, f_frsize=3D4096}) = =3D 0 close(6) =3D 0 fstat(4, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 read(5, "\3\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0", 20) =3D 16 open("foo", O_RDONLY|O_NONBLOCK) =3D -1 ENOENT (No such file or dire= ctory) lstat("foo", 0x7ffee174c3b0) =3D -1 ENOENT (No such file or dire= ctory) write(2, "tail: ", 6) =3D 6 write(2, "foo", 3) =3D 3 write(2, ": No such file or directory", 27) =3D 27 write(2, "\n", 1) =3D 1 close(4) =3D 0 read(5, "\3\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0", 20) =3D 16 inotify_rm_watch(5, 3) =3D -1 EINVAL (Invalid argument) --8<---------------cut here---------------end--------------->8--- For a *failing* execution (armhf), we get: --8<---------------cut here---------------start------------->8--- lstat64("a", {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 lstat64("foo", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 inotify_init() =3D 5 write(1, "=3D=3D> a <=3D=3D\nx\n\n=3D=3D> foo <=3D=3D\n", 25) =3D 25 inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) =3D 1 inotify_add_watch(5, "a", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = =3D 2 inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) =3D 1 inotify_add_watch(5, "foo", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF= ) =3D 3 open("a", O_RDONLY|O_NONBLOCK|O_LARGEFILE) =3D 6 lstat64("a", {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 fstat64(6, {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 fstatfs64(6, 88, {f_type=3D"EXT2_SUPER_MAGIC", f_bsize=3D4096, f_blocks=3D3= 7378337, f_bfree=3D36178942, f_bavail=3D34274471, f_files=3D9502720, f_ffre= e=3D9405759, f_fsid=3D{1592050960, 1812457140}, f_namelen=3D255, f_frsize= =3D4096, f_flags=3D4128}) =3D 0 close(6) =3D 0 fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D2, ...}) =3D 0 open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE) =3D 6 lstat64("foo", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstat64(6, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstatfs64(6, 88, {f_type=3D"EXT2_SUPER_MAGIC", f_bsize=3D4096, f_blocks=3D3= 7378337, f_bfree=3D36178942, f_bavail=3D34274471, f_files=3D9502720, f_ffre= e=3D9405759, f_fsid=3D{1592050960, 1812457140}, f_namelen=3D255, f_frsize= =3D4096, f_flags=3D4128}) =3D 0 close(6) =3D 0 fstat64(4, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 read(5, "\3\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0", 20) =3D 16 open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE) =3D 6 lstat64("foo", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstat64(6, {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 fstatfs64(6, 88, {f_type=3D"EXT2_SUPER_MAGIC", f_bsize=3D4096, f_blocks=3D3= 7378337, f_bfree=3D36178938, f_bavail=3D34274467, f_files=3D9502720, f_ffre= e=3D9405759, f_fsid=3D{1592050960, 1812457140}, f_namelen=3D255, f_frsize= =3D4096, f_flags=3D4128}) =3D 0 close(6) =3D 0 read(5, --8<---------------cut here---------------end--------------->8--- In both cases, reading from the inotify file descriptor (number 5) returns a notification for watch #3 (corresponding to =E2=80=98foo=E2=80=99= ), with mask IN_ATTRIB (value 4). However, the open("foo") call that immediately follows does *not* return ENOENT in the failing case: The file is still there. The kernel=E2=80=99s =E2=80=98vfs_unlink=E2=80=99 goes like this: fsnotify_link_count(target); /* IN_ATTRIB */ d_delete(dentry); /* fsnotify_nameremove =E2=86=92 IN_DELETE for = =E2=80=9C.=E2=80=9D */ So, =E2=80=98tail=E2=80=99 first receives the IN_ATTRIB notification corres= ponding to the link count decrease on =E2=80=98foo=E2=80=99; at that point, =E2=80=98f= oo=E2=80=99 is still available. And then, =E2=80=98tail=E2=80=99 should receive the IN_DELETE_S= ELF notification, at which point =E2=80=98foo=E2=80=99 would have been actually= been unlinked. But in practice we don=E2=80=99t seem to be receiving IN_DELETE_= SELF, even in the succeeding case. I think the problem happens when =E2=80=98tail=E2=80=99 opens =E2=80=98foo= =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? Thanks, Ludo=E2=80=99. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 14:19:23 2015 Received: (at control) by debbugs.gnu.org; 11 Sep 2015 18:19:23 +0000 Received: from localhost ([127.0.0.1]:57282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaSux-0002fT-7O for submit@debbugs.gnu.org; Fri, 11 Sep 2015 14:19:23 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:46058) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaSuv-0002fJ-5D for control@debbugs.gnu.org; Fri, 11 Sep 2015 14:19:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsLALEa81VtTIH4/2dsb2JhbABdglFSgRcIgWWBFU6/M4JONYErTAEBAQEBAYELQQWDfQoqVA0CBRYLAgsDAgECATkGAgIIDQgBAYguAahLj2WFb45XgSKEVo11gUMFlVaWDZFmY4FKAQEIAgGCKz2Db4ZjAgEC Received: from unknown (HELO localhost.localdomain) ([109.76.129.248]) by mail2.vodafone.ie with ESMTP; 11 Sep 2015 19:19:19 +0100 Message-ID: <55F31B26.8090406@draigBrady.com> Date: Fri, 11 Sep 2015 19:19:18 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: GNU bug tracker automated control server Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: forcemerge 21459 21460 stop [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [213.233.128.44 listed in list.dnswl.org] 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: forcemerge 21459 21460 stop [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [213.233.128.44 listed in list.dnswl.org] 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject forcemerge 21459 21460 stop From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 16:34:40 2015 Received: (at submit) by debbugs.gnu.org; 11 Sep 2015 20:34:40 +0000 Received: from localhost ([127.0.0.1]:57354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaV1r-0000V1-SO for submit@debbugs.gnu.org; Fri, 11 Sep 2015 16:34:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60165) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaV1p-0000Us-8o for submit@debbugs.gnu.org; Fri, 11 Sep 2015 16:34:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaV1n-0005d5-IV for submit@debbugs.gnu.org; Fri, 11 Sep 2015 16:34:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaV1n-0005cr-Fg for submit@debbugs.gnu.org; Fri, 11 Sep 2015 16:34:35 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaV1l-0004Xn-So for bug-guix@gnu.org; Fri, 11 Sep 2015 16:34:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaV1g-0005Z4-RQ for bug-guix@gnu.org; Fri, 11 Sep 2015 16:34:33 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:10526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaV1g-0005Yf-F6; Fri, 11 Sep 2015 16:34:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAF0681VtTIH4/2dsb2JhbABdglFSHzVpglxOsQCLCIYBAoFXTAEBAQEBAYELhCQBAQQjBAsBRhAJAg0LAgIFFgsCAgkDAgECAUUGAQwBBwEBhhKCHAGacZ0jhW+OIwEBAQEGAQEBAQEdgSKEVoV4hQ0HgmmBQwEEhzGFRohfhQqJPEaHAQyRWmOEAj0ziFeBSAEBAQ Received: from unknown (HELO localhost.localdomain) ([109.76.129.248]) by mail2.vodafone.ie with ESMTP; 11 Sep 2015 21:34:26 +0100 Message-ID: <55F33AD1.3080502@draigBrady.com> Date: Fri, 11 Sep 2015 21:34:25 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?THVkb3ZpYyBDb3VydMOocw==?= , 21459@debbugs.gnu.org Subject: Re: bug#21459: Race condition in tests/tail-2/assert.sh References: <87wpvw2ad8.fsf@gnu.org> In-Reply-To: <87wpvw2ad8.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit Cc: bug-guix@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) On 11/09/15 17:23, Ludovic Courtès wrote: > Hello, > > We have observed intermittent failures of tests/tail-2/assert.sh > (Coreutils 8.24, libc 2.22), especially showing up on relatively slow > machines (armhf and mips64el.) > > The failure is with ‘tail --follow=name’, which, in inotify mode, would > fail to report that file ‘foo’ has been deleted. > > The strace of a correct execution (x86_64) is like this: > > --8<---------------cut here---------------start------------->8--- > lstat("a", {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > lstat("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > inotify_init() = 5 > write(1, "==> a <==\nx\n\n==> foo <==\n", 25) = 25 > inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) = 1 > inotify_add_watch(5, "a", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 2 > inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) = 1 > inotify_add_watch(5, "foo", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 3 > open("a", O_RDONLY|O_NONBLOCK) = 6 > lstat("a", {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > fstat(6, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > fstatfs(6, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=16738210, f_bfree=1219533, f_bavail=367617, f_files=4259840, f_ffree=2406492, f_fsid={1622537548, 1497272261}, f_namelen=255, f_frsize=4096}) = 0 > close(6) = 0 > fstat(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > open("foo", O_RDONLY|O_NONBLOCK) = 6 > lstat("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstat(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstatfs(6, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=16738210, f_bfree=1219533, f_bavail=367617, f_files=4259840, f_ffree=2406492, f_fsid={1622537548, 1497272261}, f_namelen=255, f_frsize=4096}) = 0 > close(6) = 0 > fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > read(5, "\3\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0", 20) = 16 > open("foo", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory) > lstat("foo", 0x7ffee174c3b0) = -1 ENOENT (No such file or directory) > write(2, "tail: ", 6) = 6 > write(2, "foo", 3) = 3 > write(2, ": No such file or directory", 27) = 27 > write(2, "\n", 1) = 1 > close(4) = 0 > read(5, "\3\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0", 20) = 16 > inotify_rm_watch(5, 3) = -1 EINVAL (Invalid argument) > --8<---------------cut here---------------end--------------->8--- > > For a *failing* execution (armhf), we get: > > --8<---------------cut here---------------start------------->8--- > lstat64("a", {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > lstat64("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > inotify_init() = 5 > write(1, "==> a <==\nx\n\n==> foo <==\n", 25) = 25 > inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) = 1 > inotify_add_watch(5, "a", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 2 > inotify_add_watch(5, ".", IN_ATTRIB|IN_MOVED_TO|IN_CREATE) = 1 > inotify_add_watch(5, "foo", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 3 > open("a", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6 > lstat64("a", {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > fstat64(6, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > fstatfs64(6, 88, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=37378337, f_bfree=36178942, f_bavail=34274471, f_files=9502720, f_ffree=9405759, f_fsid={1592050960, 1812457140}, f_namelen=255, f_frsize=4096, f_flags=4128}) = 0 > close(6) = 0 > fstat64(3, {st_mode=S_IFREG|0644, st_size=2, ...}) = 0 > open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6 > lstat64("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstat64(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstatfs64(6, 88, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=37378337, f_bfree=36178942, f_bavail=34274471, f_files=9502720, f_ffree=9405759, f_fsid={1592050960, 1812457140}, f_namelen=255, f_frsize=4096, f_flags=4128}) = 0 > close(6) = 0 > fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > read(5, "\3\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0", 20) = 16 > open("foo", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 6 > lstat64("foo", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstat64(6, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > fstatfs64(6, 88, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=37378337, f_bfree=36178938, f_bavail=34274467, f_files=9502720, f_ffree=9405759, f_fsid={1592050960, 1812457140}, f_namelen=255, f_frsize=4096, f_flags=4128}) = 0 > close(6) = 0 > read(5, > --8<---------------cut here---------------end--------------->8--- > > In both cases, reading from the inotify file descriptor (number 5) > returns a notification for watch #3 (corresponding to ‘foo’), with mask > IN_ATTRIB (value 4). > > However, the open("foo") call that immediately follows does *not* return > ENOENT in the failing case: The file is still there. > > The kernel’s ‘vfs_unlink’ goes like this: > > fsnotify_link_count(target); /* IN_ATTRIB */ > d_delete(dentry); /* fsnotify_nameremove → IN_DELETE for “.” */ > > So, ‘tail’ first receives the IN_ATTRIB notification corresponding to > the link count decrease on ‘foo’; at that point, ‘foo’ is still > available. And then, ‘tail’ should receive the IN_DELETE_SELF > notification, at which point ‘foo’ would have been actually been > unlinked. But in practice we don’t seem to be receiving IN_DELETE_SELF, > even in the succeeding case. > > I think the problem happens when ‘tail’ opens ‘foo’ right in between of > the two notifications: ‘foo’ is still there, and so ‘tail’ doesn’t > report anything. > > Does that make sense? Thanks for looking into it in such detail. IN_DELETE_SELF is only sent when the inode is removed, not on the unlink itself (as tail has the file open). One of the awkward gotchas with inotify being inode oriented. I.E. I wonder is this a cache coherency issue, with tail referencing the stale inode in the open() before the dcache is updated. It'll be a while before I can look at this. thanks again, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 11 17:11:00 2015 Received: (at request) by debbugs.gnu.org; 11 Sep 2015 21:11:00 +0000 Received: from localhost ([127.0.0.1]:57435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaVb1-0002u2-Uk for submit@debbugs.gnu.org; Fri, 11 Sep 2015 17:11:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38699) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaVb0-0002tu-0D for request@debbugs.gnu.org; Fri, 11 Sep 2015 17:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaVaw-0005By-EB for request@debbugs.gnu.org; Fri, 11 Sep 2015 17:10:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaVaw-0005Bt-BH for request@debbugs.gnu.org; Fri, 11 Sep 2015 17:10:54 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:33994 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ZaVav-0007QJ-Ks for request@debbugs.gnu.org; Fri, 11 Sep 2015 17:10:54 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: request@debbugs.gnu.org Subject: merge X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 25 Fructidor an 223 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x3D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Fri, 11 Sep 2015 23:10:51 +0200 Message-ID: <87y4gc8xwk.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: request X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) merge 21459 21460 thanks (I wonder why 2 reports for Coreutils and 0 for Guix were created.) From unknown Sat Aug 16 18:47:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 31 Oct 2015 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator