Bug 59065 - /tmp/.X0-lock is not removed if clear_tmp_enable is not enabled
Summary: /tmp/.X0-lock is not removed if clear_tmp_enable is not enabled
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 5.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Mike Makonnen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-08 23:50 UTC by Eric van Gyzen
Modified: 2003-12-01 17:00 UTC (History)
0 users

See Also:


Attachments
cleartmp.diff (956 bytes, patch)
2003-12-01 12:20 UTC, Mike Makonnen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric van Gyzen 2003-11-08 23:50:15 UTC
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.

Fix: 

Perhaps someone more familiar with the rc system could suggest a fix...
How-To-Repeat: N/A
Comment 1 Kris Kennaway 2003-11-09 22:39:55 UTC
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.

Kris
Comment 2 Eric van Gyzen 2003-11-10 17:59:39 UTC
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
Comment 3 Ceri Davies freebsd_committer freebsd_triage 2003-11-11 14:55:24 UTC
Responsible Changed
From-To: freebsd-bugs->mtm

Mike, could you take a look at this please? 
It seems that some pre-rcNG functionality has not been preserved.
Comment 4 Mike Makonnen 2003-12-01 12:20:47 UTC
On Tue, Nov 11, 2003 at 06:55:56AM -0800, Ceri Davies wrote:
> Synopsis: /tmp/.X0-lock is not removed if clear_tmp_enable is not enabled
> 
> Responsible-Changed-From-To: freebsd-bugs->mtm
> Responsible-Changed-By: ceri
> Responsible-Changed-When: Tue Nov 11 06:55:24 PST 2003
> Responsible-Changed-Why: 
> Mike, could you take a look at this please?
> It seems that some pre-rcNG functionality has not been preserved.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=59065

Ok, this indeed looks like a bug. I've sent the attached patch to
re@ for approval.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3  6BF1 B239 D010 3215 D418
mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !
Comment 5 Mike Makonnen freebsd_committer freebsd_triage 2003-12-01 16:37:28 UTC
State Changed
From-To: open->closed

fix committed. 

Thanks!