Re: `du` check for directory loop avoidance

[Jeff Kirkpatrick]

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.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  `/var/named/chroot/var/named'

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."

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.5_Technical_Notes/index.html

"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)