cvs commit: src/etc/rc.d cleartmp

[Yar Tikhiy]

On Tue, Oct 17, 2006 at 10:05:28PM +0100, Ceri Davies wrote:
> 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.

I haven't used quotas for quite a while, but I used to believe that
administrative limits were stored in those files, too, not only
current usage values.  Therefore quotas on /tmp usage would be
effectively cancelled after a reboot if we just removed the files.

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

This script does recreate the X related directories after it deleted
the old content unless clear_tmp_X is set to NO.  This is also good
for mfs /tmp, which starts blank but should have the X dirs created
in it if the system is supposed to run X.

IMHO there's little reason in delegating the task of creating the
dirs to a separate script because they should be deleted first
anyway for security reasons.  And cleartmp is a boot time script,
too; it always runs from /etc/rc (but can do nothing if its rc.conf
vars are set to NO.)

Oh, perhaps it isn't clear that this script is controlled by two
partially independent rc.conf vars, clear_tmp_enable and clear_tmp_X.
Their defaults are NO and YES, respectively.  In this mode, cleartmp
removes only the X dirs from /tmp and then creates them.  If the
settings are YES and YES, it removes all from /tmp (except a few)
and then creates the X dirs.  For YES and NO, it just purges all
junk from /tmp and creates nothing.

-- 
Yar