From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26772 invoked from network); 9 Dec 2020 00:28:04 -0000 Received: from ewsd.inri.net (107.191.116.128) by inbox.vuxu.org with ESMTPUTF8; 9 Dec 2020 00:28:04 -0000 Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Tue Dec 8 19:25:01 -0500 2020 Message-ID: Date: Wed, 09 Dec 2020 01:24:49 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: <896870C4CC9317A385053A31EB9863B9@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: interface deep-learning software Subject: Re: [9front] recent changes Reply-To: 9front@9front.org Precedence: bulk i located the issue. it can be reproduced when cpuing to another machine and running window -m. the problem is that OCEXEC doesnt work too tell with /srv files. when any program opens a /srv file with OCEXEC flag, it sets the close-on-exec flag on the shared channel, resulting in all subsequent opens (regardless of the flag) to have close-on-exec semantics. that happens with the $wsys channel. it is interesting as devsrv itself tries hard to prevent you from posting a file descriptor with the close-on-exec flag set. but subsequent opens can still poison the channel. the fixes are pushed. -- cinap