[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220627142911.GC2408@voyager>
Date: Mon, 27 Jun 2022 16:29:11 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Nick Peng <pymumu@...il.com>
Subject: Re: BUG: Calling readdir/dirfd after vfork will cause
deadlock.
On Mon, Jun 27, 2022 at 12:05:41PM +0800, Nick Peng wrote:
> The feature I want to achieve is to close all file handles after fork to
> avoid file handles being inherited to child processes.
>
The normal solution to that problem is FD_CLOEXEC. I have started just
opening all FDs with FD_CLOEXEC set. If I want to bestow it upon a child
process, I can always dup() it (which clears FD_CLOEXEC from the
destination FD).
> In order to avoid file handles inheriting from child processes, we
> implemented a API like system,close all file handles after vfork.
That wouldn't be conforming to the vfork() spec either, since close() is
neither _exit() nor in the exec* family.
> The component is based on glibc, currently this program runs for about 10
> years without deadlock.
> Recently, this component is used in musl-based embedded systems, and it
> hangs often.
>
Congratulations, you found a way to make undefined behavior break your
setup only a decade after its inception. Such is the nature of the
beast. Sometimes it will work for you. Until something changes, that may
be out of your control.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
