From owner-cvs-src@FreeBSD.ORG Tue Oct 17 21:46:59 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C94516A40F; Tue, 17 Oct 2006 21:46:59 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB7A643D66; Tue, 17 Oct 2006 21:46:57 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k9HLkt4Y078868; Wed, 18 Oct 2006 01:46:56 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k9HLktov078863; Wed, 18 Oct 2006 01:46:55 +0400 (MSD) (envelope-from yar) Date: Wed, 18 Oct 2006 01:46:55 +0400 From: Yar Tikhiy To: Ceri Davies , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Maxime Henrion , Andrzej Tobola Message-ID: <20061017214655.GC75464@comp.chem.msu.su> References: <200610161301.k9GD1j0C074012@repoman.freebsd.org> <20061017173133.GD70184@comp.chem.msu.su> <20061017210527.GD92966@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061017210527.GD92966@submonkey.net> User-Agent: Mutt/1.5.9i Cc: Subject: Re: cvs commit: src/etc/rc.d cleartmp X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2006 21:46:59 -0000 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