[Top][All Lists]

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

Re: `du` check for directory loop avoidance

From: Jeff Kirkpatrick
Subject: Re: `du` check for directory loop avoidance
Date: Wed, 18 Dec 2013 14:29:22 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120601 Thunderbird/10.0.5

I don't know about items b and c, but if I understand correctly, the original message did state that it was a warning rather than an error:

WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
The following directory is part of the cycle:

That has since been replaced by the message: 
du: mount point `/var/named/chroot/var/named' already traversed

Additionally, the Red Hat Enterprise Linux 6.5 Technical Notes refers to this, not as an error but as a "descriptive warning."

"Before this update, a directory cycle induced by a bind mount was treated as a fatal error, for example a probable disk corruption. However, such cycles are relatively common and can be detected efficiently. The "du" command has been modified to display a descriptive warning and also to return the appropriate non-zero exit value. "

Based on this, I can see the customer's point. I'm not certain it's really worth a battle to address, but I can understand where he's coming from.

On 12/18/2013 02:05 PM, Eric Blake wrote:
I would argue the message is only informational, or at most a warning,
> not an error, so the non-zero rule should not apply.
If the message is not an error, then: a) it must clearly state that it
is a warning, and b) it must have a way to be silenced, preferably by a
command line option, and c) setting POSIXLY_CORRECT in the environment
must silence the warning by default.  Otherwise, it is an error, and
non-zero status is correct.

> My main concern is with scripts. This case is 100% normal and expected
> on every system that runs named chrooted, and potentially any other
> process that is run chrooted as well. Thus any script that calls du and
> wants to be robust will not be able to easily distinguish this
> completely normal and expected case from a true error case.
Then the CORRECT approach is to set different non-zero status levels;
use status 1 for this being the only message issued, and status 2 or
greater for any other, more serious error.  Scripts that care can then
check $?, and scripts that don't care about the distinction, but which
DO want to handle it as an error, can merely check for non-zero status.
 Just because it might be normal in some chroot environments doesn't
mean it is not an error in other environments.

Jeff Kirkpatrick, Support Relationship Manager
Strategic Customer Engagement
Red Hat Global Support Services

For Immediate Technical Support - 1.888.GO.REDHAT (888.467.3342)

reply via email to

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