cvs commit: src/etc/rc.d cleartmp

[Ceri Davies]

On Tue, Oct 17, 2006 at 09:31:33PM +0400, Yar Tikhiy wrote:
> On Mon, Oct 16, 2006 at 01:01:45PM +0000, Yar Tikhiy wrote:
> > yar         2006-10-16 13:01:45 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     etc/rc.d             cleartmp 
> >   Log:
> >   Improve cleartmp in a number of aspects:
> >   
> >   + Use rc.subr(8) features properly.
> >   + Do the whole job of obliterating /tmp contents in find(1).
> >   + Leave lost+found and quota.{user,group} in /tmp only if root-owned.
> >   + Make the overall structure clearer by first removing the X dirs
> >     (perhaps along with the rest of /tmp) and then re-creating them.
> >   + Use "find -exec rm -rf {} +" for efficiency: each rm instance gets
> >     a chance to kill as much files in /tmp as ARG_MAX permits.
> 
> I was asked a few times why "-prune -exec rm -rf" had been chosen
> over "-delete".  My initial reason was that -delete would keep
> bogus lost+found and quota.{user,group} entries found in subdirs
> of /tmp.  Well, on second thought, the find command line can be
> tweaked so that -delete works as wanted.  E.g.:
> 
>                 cd /tmp && find -x . ! -name . \
>                     ! \( -path ./lost+found -type d -user root \) \
>                     ! \( \( -path ./quota.user -or -path ./quota.group \) \
>                         -type f -user root \) \
>                     -delete
> 
> Note using -path in place of -name.
> 
> However, it has recently been found that our fts(3) implementation
> is unable to handle very deep trees -- see PR bin/104458.  While
> the bug hits both rm and find, rm has a better chance to recover
> from it and gain the ability to remove virtually unlimited trees
> while find is doomed to retain much more inherent limitations due
> to its complex nature.  Therefore I'm inclined to keep "-prune
> -exec rm -rf" as a more robust approach, at least potentially.
> So find has only to skim over /tmp while descending to its deeps
> is left to rm.

Given that we're deleting everything anyway, wouldn't it be possible to
remove quota.{group,user} regardless and let quotacheck recreate them if
required?  This shouldn't take too long since there won't be much there.

Also, if X requires certain directories, wouldn't it be better to blow
them away here and have them created from a boot time script?  Otherwise
I don't understand how they ever get created.

I'm aware that these are probably stupid questions with obvious answers
but I think they're still worth asking.

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20061017/4c3528d3/attachment.pgp