From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id C910D6DE024F for ; Mon, 20 Jan 2020 14:44:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.447, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FUXB4VyGXa8 for ; Mon, 20 Jan 2020 14:44:12 -0800 (PST) X-Greylist: delayed 427 seconds by postgrey-1.36 at arlo; Mon, 20 Jan 2020 14:44:12 PST Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by arlo.cworth.org (Postfix) with ESMTPS id 35C266DE023C for ; Mon, 20 Jan 2020 14:44:12 -0800 (PST) IronPort-SDR: qRURLB9kBl4mPlh+cSqIBOux/iwQBC2Muvv12RyBhKMgcA9qQ2GrCB9JY5F8nHpZeaZlCfL7oo uIQswwcrvplmMd/DhMV1/ejioRppWmb8e3WYvs1CAkBaGtlpz0qP0rnTi6Jgvdsmn8+x3ExJc7 UvcZXP7Zmz1CVi7zM+T1ZSi1AzF4KTZVk5CWoiZXL+xQla1HfFwlTuGVdC7ak6x7ctSVst8ffm OzQgDMBeXPz2f92Tx/cAhsVdOvOlaKWIcQTftVKtS/KXWssHa9kxsHoYaljVz0A3pV+hKFhuH8 LRA= X-IronPort-AV: E=Sophos;i="5.70,343,1574150400"; d="scan'208";a="46949333" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 20 Jan 2020 14:37:02 -0800 IronPort-SDR: G/M2SKxY2EtVPXpc2wbppDy9s7uSDeWAn3KjEZcbVeG1kHo4/h2jz7YFJT9xpJMwj0r+B0AANm WXzgj5KKZ49Q== From: Thomas Schwinge To: Subject: Re: notmuch vs. SIGPIPE In-Reply-To: <87h80qgx5b.fsf@euler.schwinge.homeip.net> References: <87h80qgx5b.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.1+93~g67ed7df (https://notmuchmail.org) Emacs/26.1 (x86_64-pc-linux-gnu) Date: Mon, 20 Jan 2020 23:36:51 +0100 Message-ID: <87ftg93gcc.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 22:44:13 -0000 Hi! On 2020-01-20T12:55:28+0100, I wrote: > While looking a bit into the item raised in > id:87muamgspy.fsf@euler.schwinge.homeip.net I noticed the following > (mis?)behavior by notmuch. > > To set the stage: > > $ yes | head -n 1 > y > $ echo "${PIPESTATUS[@]}" > 141 0 > > As expected, the 'yes' process exits with SIGPIPE right after the 'head' > process terminated. See also , for example. > However: > > $ notmuch search \* | head -n 1 & sleep 22; jobs; ps -f > [1] 622009 > thread:0000000000032bb2 the future [1/1] Jenna Moss; Steve Burbon, = Washington (hurd list spam) > [1]+ Running notmuch search \* | head -n 1 & > UID PID PPID C STIME TTY TIME CMD > thomas 621851 4297 0 12:38 pts/38 00:00:00 /bin/bash > thomas 622008 621851 99 12:48 pts/38 00:00:22 /home/thomas/comm= and/notmuch.real search \* > thomas 622013 621851 0 12:48 pts/38 00:00:00 ps -f > > Even after its "pipe-consumer" 'head' process has terminated, the > 'notmuch' process still keeps running, and running, and running... It > has to be killed manually (unless it before exits because of concurrent > database modification). This doesn't seem expected behavior to me? > > Now, I do have a patch or two (actually dozensa; reverts, WIP etc.) on > top of months-old notmuch sources, so I'll later try to reproduce that > with clean sources. $ gdb -q --args notmuch dump Reading symbols from notmuch... (gdb) break sigaction Breakpoint 1 at 0xe130 (gdb) r Starting program: [...]/notmuch dump [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.= 1". =20=20=20=20 Breakpoint 1, __GI___sigaction (sig=3D13, act=3D0x0, oact=3D0x7fffffffd= 4e0) at ../nptl/sigaction.c:24 24 ../nptl/sigaction.c: No such file or directory. (gdb) bt #0 0x00007ffff77e92f0 in __GI___sigaction (sig=3D13, act=3D0x0, oact= =3D0x7fffffffd4e0) at ../nptl/sigaction.c:24 #1 0x00007ffff75bfa8d in () at /usr/lib/x86_64-linux-gnu/libgpgme.so.= 11 #2 0x00007ffff75c64cd in gpgme_check_version () at /usr/lib/x86_64-lin= ux-gnu/libgpgme.so.11 #3 0x00007ffff75c6667 in gpgme_check_version_internal () at /usr/lib/x= 86_64-linux-gnu/libgpgme.so.11 #4 0x00007ffff7f456b3 in g_mime_init () at /usr/lib/x86_64-linux-gnu/l= ibgmime-3.0.so.0 #5 0x000055555556539d in main (argc=3D2, argv=3D0x7fffffffd828) at not= much.c:469 So, libgpgme via libgmime initialization is doing something with signals. Here, 'sig=3D13' is SIGPIPE, 'act=3D0x0' means to just query, and store current handling into 'oact': (gdb) finish Run till exit from #0 __GI___sigaction (sig=3D13, act=3D0x0, oact=3D0x= 7fffffffd4e0) at ../nptl/sigaction.c:24 0x00007ffff75bfa8d in ?? () from /usr/lib/x86_64-linux-gnu/libgpgme.so.= 11 Value returned is $1 =3D 0 (gdb) print *(struct sigaction *) 0x7fffffffd4e0 $2 =3D {__sigaction_handler =3D {sa_handler =3D 0x0, sa_sigaction =3D 0= x0}, sa_mask =3D {__val =3D {0, 8, 93824992565632, 0, 32, 88, 0, 22, 0, 140= 733193388034, 93823560581120, 7, 93824992559120, 32, 5, 93824992694848}}, s= a_flags =3D 0, sa_restorer =3D 0x0} A '0x0' '__sigaction_handler' means 'SIG_DFL', which for SIGPIPE means to terminate the process. This is as expected. However, then: (gdb) continue=20 Continuing. =20=20=20=20 Breakpoint 1, __GI___sigaction (sig=3D13, act=3D0x7fffffffd4e0, oact=3D= 0x0) at ../nptl/sigaction.c:24 24 in ../nptl/sigaction.c (gdb) bt #0 0x00007ffff77e92f0 in __GI___sigaction (sig=3D13, act=3D0x7fffffffd= 4e0, oact=3D0x0) at ../nptl/sigaction.c:24 #1 0x00007ffff75bfadc in () at /usr/lib/x86_64-linux-gnu/libgpgme.so.= 11 #2 0x00007ffff75c64cd in gpgme_check_version () at /usr/lib/x86_64-lin= ux-gnu/libgpgme.so.11 #3 0x00007ffff75c6667 in gpgme_check_version_internal () at /usr/lib/x= 86_64-linux-gnu/libgpgme.so.11 #4 0x00007ffff7f456b3 in g_mime_init () at /usr/lib/x86_64-linux-gnu/l= ibgmime-3.0.so.0 #5 0x000055555556539d in main (argc=3D2, argv=3D0x7fffffffd828) at not= much.c:469 (gdb) print *act $3 =3D {__sigaction_handler =3D {sa_handler =3D 0x1, sa_sigaction =3D 0= x1}, sa_mask =3D {__val =3D {0 }}, sa_flags =3D 0, sa_res= torer =3D 0x0} A '0x1' '__sigaction_handler' means 'SIG_IGN', ignore any such signals. This is unexpected (to me, at least), not what I'd expect with notmuch? According to a (very quick) check/survey, this has apparently been the case "forever", and is documented on , together with some rationale. Aha, aha, OK, I see. So, assuming we want to keep it that way (given the gpgme rationale), is the problem then that we fail to handle appropriately in notmuch any EPIPE that we may be getting from 'write' etc.? This remains to be explored another day. Gr=C3=BC=C3=9Fe Thomas