clean out /tmp?

[Morgan Read]

Hi,
Is there a way to keeping my /tmp's cleaned out in FC?

I had what I thought was the perfect answer to keeping my /tmp's trim and in
shape by using cron scripts - but, it appears to apply to suse only?  (See
bellow.)

Regards,
Morgan.

-------- Original Message --------
Subject: Re: [nzlug] clean out /tmp?
Date: Mon, 26 Sep 2005 09:53:21 +1200
From: Volker Kuhlmann 
Reply-To: NZLUG Mailing List 
To: NZLUG Mailing List 
References: 

	
> I got to having a look at this cron file and I have no /etc/sysconfig/cron.
> I'm running FC4, is it likely to have a different set-up?

Looks like it, yes. I use SuSE.
> Other things that may be relevant:
> /etc/cron.d/ (empty)
> /etc/cron.hourly/ -> ... /cron.monthly/
> /etc/crontab

This is the mechanism to control a standard unix cron daemon. In turn,
the scripts in these directories (and in /etc/init.d/) read
/etc/sysconfig/cron and act on it.
> /etc/sysconfig/crond (which doesn't contain the text)

This looks like it's the equivalent file for FC. If you can't find any
commments in this file relating to clearing temp directories, than I'd
conclude that FC isn't as sophisticated in this department.
> If your /etc/sysconfig/cron isn't personal, can you copy it across (and
> would it work)?

The file is not personal, you can find it in the package
ftp://ftp.opensuse.org/pub/opensuse/distribution/SL-10.0-OSS-RC1/inst-source/suse/i586/aaa_base-10.0-27.i586.rpm
at /var/adm/fillup-templates/sysconfig.cron. No it would not work unless
you also installed the (parts of) the scripts which read this file.
These are
/etc/init.d/boot.cleanup
/etc/cron.daily/suse.de-clean-tmp
in the same package. You're on your own surgically implanting the
correct parts into FC.
> > The easiest would seem to be to edit /etc/sysconfig/cron and the system
> > will do the rest. The guts of that are below.
> >
> > Volker
> >
> > # cron.daily can check for old files in tmp-dirs. It will delete all files
> > # not accessed for more than MAX_DAYS_IN_TMP. If MAX_DAYS_IN_TMP is not set
> > # or set to 0, this feature will be disabled. 
> > #
> > MAX_DAYS_IN_TMP="7"
> >
> > ## Type:	string
> > ## Default:	"/tmp"
> > #
> > # This variable contains a list of directories, in which old files are to
> > # be searched and deleted. The frequency is determined by MAX_DAYS_IN_TMP
> > #
> > TMP_DIRS_TO_CLEAR="/tmp /var/tmp"
> >
> > # "Set this to "yes" to entirely remove (rm -rf) all  files and subdirectories
> > # from the temporary directories defined in TMP_DIRS_TO_CLEAR on bootup.
> > # Please note, that this feature ignores OWNER_TO_KEEP_IN_TMP - all files will
> > # be removed without exception."
> > #
> > # If this is set to a list of directories (i.e. starts with a "/"), these
> > # directories will be cleared instead of those listed in TMP_DIRS_TO_CLEAR.
> > # This can be used to clear directories at boot as well as clearing unused
> > # files out of other directories.
> > #
> > CLEAR_TMP_DIRS_AT_BOOTUP="/tmp"

HTH,

Volker

[Michael A. Peters]

On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> Hi,
> Is there a way to keeping my /tmp's cleaned out in FC?

Nothing in /tmp should be expected to survive a reboot.
In fact, some people like to run /tmp as a tempfs (temporary file
system) - only problem is, a tempfs can get full if you aren't careful.

But you can write an init script to delete it all at shutdown (or
startup). Or just do what I do - ignore it, if space ever gets tight -
then I boot into runlevel 3 and clear it (you don't want to clear it
with X running)

[Jeff Vian]

On Mon, 2005-09-26 at 15:08 -0700, Michael A. Peters wrote:
> On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> > Hi,
> > Is there a way to keeping my /tmp's cleaned out in FC?
>
> Nothing in /tmp should be expected to survive a reboot.
> In fact, some people like to run /tmp as a tempfs (temporary file
> system) - only problem is, a tempfs can get full if you aren't careful.
>
> But you can write an init script to delete it all at shutdown (or
> startup). Or just do what I do - ignore it, if space ever gets tight -
> then I boot into runlevel 3 and clear it (you don't want to clear it
> with X running)

You can easily also extend the init script to work for runlevel 3,6,1,0
so it will clear /tmp whenever going to those runlevels.

[James Wilkinson]

Michael A. Peters wrote:
> Nothing in /tmp should be expected to survive a reboot.
> In fact, some people like to run /tmp as a tempfs (temporary file
> system) - only problem is, a tempfs can get full if you aren't careful.

So can a regular /tmp.

Modern tmpfs uses both memory and swap-space, depending on "memory
pressure" (whether the kernel thinks it has a better use for real memory
than using it for a particular tmpfs page). It has a
sysadmin-configurable maximum size: "the default is half of your
physical RAM without swap", but you can dynamically change that.

So you can add (some of) the disk space you would have used for /tmp to
swap space, and either reclaim a bit of space, or get extra protection
against /tmp or memory filling up.

I'd also note that there are worse things that can happen to a server
than /tmp getting full. For example, the filesystem containing
/var/spool on a mailserver. If you just have the one filesystem, then
/tmp filling that filesystem will obviously lead to /var/spool's
filesystem being full...

Putting this in /etc/fstab should work:
none           /tmp         tmpfs defaults,nodev 0 0

(You may not want to set nodev, or set noexec as well...)

See /usr/src/linux/Documentation/filesystems/tmpfs.txt or
http://lxr.linux.no/source/Documentation/filesystems/tmpfs.txt for more
details.

Finally, I'd note that the FHS explicitly *recommends* that /tmp be
cleared out on system boot, and requires that "Programs must not assume
that any files or directories in /tmp are preserved between invocations
of the program."
(http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES).

Hope this helps,

James.

[Michael A. Peters]

On Mon, 2005-09-26 at 23:57 +0100, James Wilkinson wrote:
> Michael A. Peters wrote:
> > Nothing in /tmp should be expected to survive a reboot.
> > In fact, some people like to run /tmp as a tempfs (temporary file
> > system) - only problem is, a tempfs can get full if you aren't careful.
>
> So can a regular /tmp.
>
> Modern tmpfs uses both memory and swap-space, depending on "memory
> pressure" (whether the kernel thinks it has a better use for real memory
> than using it for a particular tmpfs page). It has a
> sysadmin-configurable maximum size: "the default is half of your
> physical RAM without swap", but you can dynamically change that.

Yeah - for the desktop user though, if you are doing a lot of
downloading it can end up being a real pain if your download agent
uses /tmp and suddenly you lose the download because your tempfs ran out
of space.

For desktops, I think it really is best for /tmp to be part of your root
logical volume group.

That being said - when I did sysadmin work, both /tmp and /var/run were
tempfs (/var/run was tempfs for faster access to lock/pid files - and
given a reboot after kernel update, you would never have stale pids
blocking a service. How much of a difference it really made, I haven't a
clue. Just what I was taught by dad - but it may not matter these days).
Running /var/run on tempfs is a bit tricky in RH though, after it mounts
you have to create directory structure that certain init scripts will
expect to be there.

[Mike McCarty]

Michael A. Peters wrote:
> On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> > Hi,
> > Is there a way to keeping my /tmp's cleaned out in FC?
>
> Nothing in /tmp should be expected to survive a reboot.
> In fact, some people like to run /tmp as a tempfs (temporary file
> system) - only problem is, a tempfs can get full if you aren't careful.
>
> But you can write an init script to delete it all at shutdown (or
> startup). Or just do what I do - ignore it, if space ever gets tight -
> then I boot into runlevel 3 and clear it (you don't want to clear it
> with X running)

I've been doing that ($ rm /tmp/*) while up (I use Gnome over Xwindow).
Am I playing with fire? What are the possible consequences?

Mike

[James Wilkinson]

Mike McCarty wrote:
> I've been doing that ($ rm /tmp/*) while up (I use Gnome over Xwindow).
> Am I playing with fire? What are the possible consequences?

One of your programs crashes or misbehaves...

$ ls /tmp
gconfd-james
kde-james
keyring-ZVLx1O
ksocket-james
mapping-james
mutt-kendrick-9370-37
mutt-kendrick-9370-39
orbit-james
OSL_PIPE_1000_SingleOfficeIPC_e32f75f462372e1461e8d86badb258d
ssh-jsciMW2895
xses-james.VRKZEi

(That's on a tmpfs filesystem, on a system that's been up since this
morning. So any files are those that have been created and used today.)

I don't pretend to know exactly what all of them do. But you might
expect there to be potential problems with one of them.

For example, if I were to finish editing this e-mail, exit vim, delete
all the mutt-kendrick files, then ask mutt to send this e-mail, I
wouldn't expect there to be any copy of this e-mail left for mutt to
send...

The orbit directory might worry me: I don't know enough about ORBit to
be sure deleting it wouldn't affect anything.

One other consequence you might not expect: on Unix systems, files can
appear in the directory tree more than once (hard links). Once a program
has a file open, it refers to it by a file handle, not a file name.

All rm does is unlink the specified files: a file is only deleted when
its link count goes to zero and no program still has it open. So if a
program has a temporary file open, and you rm it, it's still present on
disk (or in tmpfs), and the program can still use it, until the program
exits or closes the file.

(Some programs use this to create and use per-process temporary files
that don't appear in the directory listing. That way, if the program or
the machine crashes, the temporary files will automatically be cleaned
up. You also hear of database machines where the main database is
accidentally rm'ed. But all is not lost: the database is not deleted
until all existing programs that have direct connections to it are
deleted. So those existing connections can be used to dump the data in
the database, and it can be recreated...)

Note that neither your or my commands shows the hidden files in /tmp.

James.

[Mike McCarty]

Michael A. Peters wrote:
> On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> > Hi,
> > Is there a way to keeping my /tmp's cleaned out in FC?
>
> Nothing in /tmp should be expected to survive a reboot.
> In fact, some people like to run /tmp as a tempfs (temporary file
> system) - only problem is, a tempfs can get full if you aren't careful.
>
> But you can write an init script to delete it all at shutdown (or
> startup). Or just do what I do - ignore it, if space ever gets tight -
> then I boot into runlevel 3 and clear it (you don't want to clear it
> with X running)

Then what about tmpwatch? Mine runs daily with 720 hours as the
parameter. Isn't this a problem?

Mike

[Alexander Dalloz]

Am Mo, den 26.09.2005 schrieb Morgan Read um 23:48:
> Is there a way to keeping my /tmp's cleaned out in FC?
>
> I had what I thought was the perfect answer to keeping my /tmp's trim and in
> shape by using cron scripts - but, it appears to apply to suse only?  (See
> bellow.)
> Morgan.

May I ask what your problem is? What you quoted in the attached mail is
SuSE specific. For Fedora, some things are deleted at system start by
execution of /etc/rc.sysinit and by the /etc/cron.daily/tmpwatch
cronjob.

Alexander

[Morgan Read]

Alexander Dalloz wrote:
> Am Mo, den 26.09.2005 schrieb Morgan Read um 23:48:

...
> > Morgan.
>
> May I ask what your problem is? What you quoted in the attached mail is

...
Well, there's just a lot of stuff in there...  I'd like it to be empty when
I boot my machine, and it's not.

M.

[Jeff Vian]

On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> Hi,
> Is there a way to keeping my /tmp's cleaned out in FC?
>
> I had what I thought was the perfect answer to keeping my /tmp's trim and in
> shape by using cron scripts - but, it appears to apply to suse only?  (See
> bellow.)

See my notes below.  It is automatic and built-in.
> Regards,
> Morgan.
>
> -------- Original Message --------
> Subject: Re: [nzlug] clean out /tmp?
> Date: Mon, 26 Sep 2005 09:53:21 +1200
> From: Volker Kuhlmann 
> Reply-To: NZLUG Mailing List 
> To: NZLUG Mailing List 
> References: 
>
> 	
> > I got to having a look at this cron file and I have no /etc/sysconfig/cron.
> > I'm running FC4, is it likely to have a different set-up?
>
> Looks like it, yes. I use SuSE.
> > Other things that may be relevant:
> > /etc/cron.d/ (empty)
> > /etc/cron.hourly/ -> ... /cron.monthly/
> > /etc/crontab
>
> This is the mechanism to control a standard unix cron daemon. In turn,
> the scripts in these directories (and in /etc/init.d/) read
> /etc/sysconfig/cron and act on it.

/etc/crontab is the global crontab file.  In FC the users crontab files
are located in /var/spool/cron.

Periodic crontab scripts that are run regularly (hourly, daily, weekly,
monthly, etc. are in the appropriate /etc/cron.XXXX directories.
In /etc/cron.daily I see the script tmpwatch (/etc/cron.daily/tmpwatch)
which seems to me to do what you are asking and more.  I never see any
old files existing except the ones that are excluded in that script.

FC has a default procedure for keeping /tmp cleared.  If you need
something more specific, you could either write your own script or
modify the default and it will work for you.
> > /etc/sysconfig/crond (which doesn't contain the text)
>
> This looks like it's the equivalent file for FC. If you can't find any
> commments in this file relating to clearing temp directories, than I'd
> conclude that FC isn't as sophisticated in this department.

This file (/etc/sysconfig/crond) is used to configure crond at startup
only.  It is not the same as in Suse.
> > If your /etc/sysconfig/cron isn't personal, can you copy it across (and
> > would it work)?
>
> The file is not personal, you can find it in the package
> ftp://ftp.opensuse.org/pub/opensuse/distribution/SL-10.0-OSS-RC1/inst-source/suse/i586/aaa_base-10.0-27.i586.rpm
> at /var/adm/fillup-templates/sysconfig.cron. No it would not work unless
> you also installed the (parts of) the scripts which read this file.
> These are
> /etc/init.d/boot.cleanup
> /etc/cron.daily/suse.de-clean-tmp
> in the same package. You're on your own surgically implanting the
> correct parts into FC.
> > > The easiest would seem to be to edit /etc/sysconfig/cron and the system
> > > will do the rest. The guts of that are below.

see above.
> > > Volker
> > >
> > > # cron.daily can check for old files in tmp-dirs. It will delete all files
> > > # not accessed for more than MAX_DAYS_IN_TMP. If MAX_DAYS_IN_TMP is not set
> > > # or set to 0, this feature will be disabled. 
> > > #
> > > MAX_DAYS_IN_TMP="7"
> > >
> > > ## Type:	string
> > > ## Default:	"/tmp"
> > > #
> > > # This variable contains a list of directories, in which old files are to
> > > # be searched and deleted. The frequency is determined by MAX_DAYS_IN_TMP
> > > #
> > > TMP_DIRS_TO_CLEAR="/tmp /var/tmp"
> > >
> > > # "Set this to "yes" to entirely remove (rm -rf) all  files and subdirectories
> > > # from the temporary directories defined in TMP_DIRS_TO_CLEAR on bootup.
> > > # Please note, that this feature ignores OWNER_TO_KEEP_IN_TMP - all files will
> > > # be removed without exception."
> > > #
> > > # If this is set to a list of directories (i.e. starts with a "/"), these
> > > # directories will be cleared instead of those listed in TMP_DIRS_TO_CLEAR.
> > > # This can be used to clear directories at boot as well as clearing unused
> > > # files out of other directories.
> > > #
> > > CLEAR_TMP_DIRS_AT_BOOTUP="/tmp"
>
> HTH,
>
> Volker

[Morgan Read]

Jeff Vian wrote:
> On Tue, 2005-09-27 at 09:48 +1200, Morgan Read wrote:
> > Hi,

...
> See my notes below.  It is automatic and built-in.

Thanks, that's pretty much what I think I want.
...
> In /etc/cron.daily I see the script tmpwatch (/etc/cron.daily/tmpwatch)
> which seems to me to do what you are asking and more.  I never see any

So, does that run at start up?  Or, daily at a given time?  It sounds as if
it runs at a given time each day - but, from what you say it runs at start up?

Regards,
M.

[Markku Kolkka]

Morgan Read kirjoitti viestissään (lähetysaika tiistai, 27. 
syyskuuta 2005 12:34):
> So, does that run at start up?  Or, daily at a given time?  It
> sounds as if it runs at a given time each day - but, from what
> you say it runs at start up?

If you keep your machine running 24h/day it runs at a given time 
(4:02 AM), if your machine is shut down at that time it will be 
run 65 minutes after startup.

[Morgan Read]

Markku Kolkka wrote:
> Morgan Read kirjoitti viestissään (lähetysaika tiistai, 27. 
> syyskuuta 2005 12:34):
> > So, does that run at start up?  Or, daily at a given time?  It
> > sounds as if it runs at a given time each day - but, from what
> > you say it runs at start up?
>
> If you keep your machine running 24h/day it runs at a given time 
> (4:02 AM), if your machine is shut down at that time it will be 
> run 65 minutes after startup.

Thanks,
M.