Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jun 2022 16:29:11 +0200
From: Markus Wichmann <>
Cc: Nick Peng <>
Subject: Re: BUG: Calling readdir/dirfd after vfork will cause

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.


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.