[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29038: df hangs on fifos/named pipes

From: Stephane Chazelas
Subject: bug#29038: df hangs on fifos/named pipes
Date: Sat, 28 Oct 2017 08:18:11 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

test case:

   mkfifo p
   df p

That hangs, unless you make "p" non-readable or some other process
has the fifo open in write mode.

The reason is that df tries to open the fifo in read-only mode,
according to comments in the source code so as to trigger a
potential automout.

That goes back to this commit:

> commit dbd17157d7e693b8de9737f802db0e235ff5a3e6
> Author: Tomas Smetana <address@hidden>
> Date:   Tue Apr 28 11:21:49 2009 +0200
>     df: use open(2), not stat, to trigger automounting
>     * src/df.c (main): When iterating over command-line arguments,
>     attempting to ensure each backing file system is mounted, use
>     open, not stat.  stat is no longer sufficient to trigger
>     automounting, in some cases.  Based on a suggestion from Ian Kent.
>     More details in http://bugzilla.redhat.com/497830

More info at the bugzilla link.

It's arguable whether df, a reporting tool, should have such a
side effect as automounting a file system.

The fifo issue though is a bug IMO, especially considering that
POSIX explicitely says that df should work on fifos.

Here, it may be enough to add the O_DIRECTORY flag to open()
where available if we only care about automounting files of type
directory (or portably use opendir()).

Or use O_PATH  on Linux 3.6+ followed by openat() on non-fifos if
open(O_PATH) is not enough to trigger the automount in the
unlikely event we care about automounting non-directory files
(and report their disk usage).

Or not open() at all, and not automount file systems.

Note that busybox, heirloom or ast-open df implementations on
Linux don't have the problem (and presumably don't automount
file systems). Nor does FreeBSD.

Reproduced with:

$ df --version
df (GNU coreutils) 8.25


$ df --version
df (GNU coreutils) 8.27.46-e13fe

That was discovered by Martijn Dekker, CCed, when looking for a
portable way to identify the file system of an arbitrary file.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]