From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 10 10:00:40 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE0C16A4CE for ; Mon, 10 Nov 2003 10:00:40 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2263943FBF for ; Mon, 10 Nov 2003 10:00:39 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id hAAI0cFY040484 for ; Mon, 10 Nov 2003 10:00:38 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id hAAI0cpP040483; Mon, 10 Nov 2003 10:00:38 -0800 (PST) (envelope-from gnats) Date: Mon, 10 Nov 2003 10:00:38 -0800 (PST) Message-Id: <200311101800.hAAI0cpP040483@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Eric van Gyzen Subject: Re: conf/59065: /tmp/.X0-lock is not removed if clear_tmp_enable is not enabled X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Eric van Gyzen List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2003 18:00:40 -0000 The following reply was made to PR conf/59065; it has been noted by GNATS. From: Eric van Gyzen To: Kris Kennaway Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: conf/59065: /tmp/.X0-lock is not removed if clear_tmp_enable is not enabled Date: Mon, 10 Nov 2003 12:59:39 -0500 Kris Kennaway wrote: > On Sat, Nov 08, 2003 at 05:39:19PM -0500, Eric van Gyzen wrote: > > >Description: > > The /tmp/.X0-lock file is removed by /etc/rc.d/cleartmp, which runs only > > if the clear_tmp_enable variable is true. The file should be removed on > > boot, unconditionally. > > I think you got precisely the behaviour you asked for. Many > applications use /tmp for storage of lock files and other temporary > data - if you want them to restart correctly after a reboot, clear > /tmp. It's true that many applications -- and users -- use /tmp for storage of various things...so many and so various, in fact, that clearing it at boot is too drastic in some environments. There might be plenty of reasons not to clear /tmp; that's why it's not done by default. X is a well-known application that practically everyone uses, and there is no imaginable reason NOT to remove the lock file. It is a special case of a lock file that just happens to be stored in /tmp. If it were stored in /var/run along with various other lock files (rpcbind.lock, ypbind.lock), it would be removed unconditionally by the cleanvar rc script. In fact, the old rc system /did/ remove it unconditionally regardless of clear_tmp_enable: # Clearing /tmp at boot-time seems to have a long tradition. It doesn't # help in any way for long-living systems, and it might accidentally # clobber files you would rather like to have preserved after a crash [snip] case ${clear_tmp_enable} in [snip] esac # Remove X lock files, since they will prevent you from restarting X11 # after a system crash. # rm -f /tmp/.X*-lock rm -fr /tmp/.X11-unix mkdir -m 1777 /tmp/.X11-unix Eric -- Eric van Gyzen Sr. Systems Programmer http://www.stat.duke.edu/~vangyzen/ ISDS, Duke University