Re: `du` check for directory loop avoidance

[Ondrej Vasik]

On Wed, 2013-12-18 at 14:29 -0600, Jeff Kirkpatrick wrote:
> 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.

But if you don't stop reading at the "warning" level, you see NON-ZERO
exit value.

I think the best solution here for customer would be to have some simple
wrapper script, setting the exit value to zero, if the df only error
output is "already traversed". This could work and not break POSIXly
correct behaviour.

As to technical notes - maybe it is a bit unfortunate formulation -
still it does contain info about non-zero exit value thus administrator
should be aware of it. Note that the du with named chroot active always
produced the warning and non-zero exit code on RHEL-6, so the scripts
should already be aware of it or they were broken even before the 6.5
update.

Eric is right, filing RFE will not help here much - you can achieve what
you want with simple wrapper. The only way I can imagine is to add
POSIXLY_CORRECT check in FTS_DC branch - as we already have some
"examples" of not completely followed POSIX (which may be overriden by
this envvar). I don't think upstream will be very keen about it, though
the impact on code would be relatively minor.

Greetings,
         Ondrej