Why does Fedora not clear /tmp?

[mikeym]

Hi,

I'm new to Fedora, and having just hit a bug because my /tmp still has files from all my previous runs, I was wondering why /tmp isn't cleared on shutdown in Fedora?


PS: The bug was a dialogue:

Could not create ICE listening Socket:
Cannot establish any listening sockets.

As soon as I logged into Gnome 3, which asked me to Logout and back in.

Looking it up I found that apparently libICE does a poor job of creating a unique socket path, basing it on the PID and putting it in /tmp/.ICE-unix/.

So my guess would be that having old sockets lying around in /tmp increases my risk of libICE freaking out. So what is the rational behind not clearing it?

[sea]

You may, change /etc/fstab.

Add (or replace) the line with /tmp and write instead:

tmpfs /tmp /tmpfs defaults 0 0

This will make your /tmp a temporary filesystem, that only stores onto ram, thus, beeing completly ereased on shutdown/reboot.
Hope this helps.

[mikeym]

Is it not a bit mental putting the whole of /tmp in ram just so it's cleared? I've run a system like that before but that was where I had to reduce disk access to as little as possible.

I wonder if I should report it as a separate Fedora bug, as the combination of /tmp remaining uncleared and libICE not creating unique paths likely makes the bug more probable.

[sea]

You may have a script that deletes the contents of /tmp.
If you run that script by cron (@hourly /path/toscript ... should suffice), it should be a root cron.

[mikeym]

Thanks.

I'm in the process of following your first suggestion to put /tmp as tmpfs, but I'm finding some odd behaviour.

I tried adding this to my /etc/fstab which from what I can find online is pretty standard for /tmp for security it is mounted with a few extra options:

tmpfs   /tmp   tmpfs   nodev,noexec,nosuid   0 0

Which when I boot crashes me out when starting X11 with this:

[     9.008] (**) Option "xkb_options" "terminate:ctrl_alt_bksp,"
[    10.275] 
Backtrace:
[    10.281] 0: /usr/bin/Xorg (xorg_backtrace+0x2f) [0x45e84f]
[    10.281] 1: /usr/bin/Xorg (0x400000+0x62ed6) [0x462ed6]
[    10.281] 2: /lib64/libpthread.so.0 (0x37bb200000+0xeef0) [0x37bb20eef0]
[    10.281] 3: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0x1002b44) [0x381a402b44]
[    10.281] 4: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0x12617c8) [0x381a6617c8]
[    10.281] 5: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0xdd1d83) [0x381a1d1d83]
[    10.281] 6: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0x126d060) [0x381a66d060]
[    10.281] 7: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0xdddb91) [0x381a1ddb91]
[    10.281] 8: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0xff0b10) [0x381a3f0b10]
[    10.281] 9: /usr/lib64/nvidia/libnvidia-glcore.so.280.13 (0x3819400000+0xfd174d) [0x381a3d174d]
[    10.281] 10: /usr/lib64/xorg/modules/extensions/nvidia/libglx.so (0x7f3aefc24000+0x458797) [0x7f3af007c797]
[    10.281] Segmentation fault at address 0xfffffffffffffff8
[    10.281] 
Fatal server error:
[    10.281] Caught signal 11 (Segmentation fault). Server aborting
[    10.281] 
[    10.281]

I traced the problem to the noexec option, and it boots fine without it. I've no idea why this would be a problem, SELinux????

---------- Post added at 11:59 AM ---------- Previous post was at 11:35 AM ----------

No, it's an NVidia proprietary driver bug, NVidia is trying to set an EXEC flag on files in /tmp. Apparently it's being worked on.

[jpollard]

You may have a script that deletes the contents of /tmp.
If you run that script by cron (@hourly /path/toscript ... should suffice), it should be a root cron.

You really don't want to do that.

A number of editors (not to mention, compilers) put workspace files in /tmp - if you wipe them out you may loose your edit... or get a corrupted result.

Also, X puts domain socket files there for connections. Wiping that out will destroy your ability to create windows.

This appears to be a bug in libICE or an improper SELinux labeling of /tmp. /tmp is supposed to have the label system_u:object_r:tmp_t:s0. You can check the label with ls -lZd /tmp

[sea]

Didnt know about the issue with compilers, but now as you said, its obvious.
Then a script at startup or shutdown would be a better choice?
Or none of the above?

I'm not experienced enough to know enough about other settings than "defaults".
It works fine for me.

[mikeym]

drwxrwxrwt. root root system_u:object_r:tmp_t:s0       /tmp

I think it's definitely a NVidia bug.

Yes the hourly wipe of /tmp is a bad idea, but I'm sure you could write a service that runs on showdown to do it.

Anyway I'm going to stick to tmpfs for now and see how I get on.

[jpollard]

Running one on shutdown usually works - but it must be the very last thing done - it has occurred that some shutdown scripts also use /tmp for scratch while closing processes down, though the ones I've seen are on fairly large servers (waiting for batch jobs to close down can take a long time... up to an hour depending on the size of the system).

[mikeym]

sea, the modifiers I posted:

nodev,noexec,nosuid

Are recommended for security. They stop users making devices, executing programs or setting user id bit in /tmp.

I've also set ",size=2G" to give plenty of space. See here.

[jpollard]

Good choice.

They are also good for any filesystem general users can write to (though the "noexec" can be dropped from a home filesystem if users are developing programs).

[sea]

sea, the modifiers I posted:

nodev,noexec,nosuid

Are recommended for security. They stop users making devices, executing programs or setting user id bit in /tmp.

I've also set ",size=2G" to give plenty of space. See here.

Thanks, this sounds good for an office enviroment, but imo not for single user use.

[jpollard]

Um. There is no difference between an "office environment" and "single user use".

both are aimed at a single user.

[dd_wizard]

There's also tmpwatch:

$ man tmpwatch

TMPWATCH(8)                     System Administrator's Manual                     TMPWATCH(8)

NAME
       tmpwatch - removes files which haven't been accessed for a period of time

SYNOPSIS
       tmpwatch [-u|-m|-c] [-MUXadfqstvx] [--verbose] [--force] [--all]
                      [--nodirs] [--nosymlinks] [--test] [--fuser] [--quiet]
                      [--atime|--mtime|--ctime] [--dirmtime] [--exclude path]
                      [--exclude-user user] [--exclude-pattern pattern]
                      time dirs

DESCRIPTION
       tmpwatch recursively removes files which haven't been accessed for a given time.  Nor-
       mally, it's used to clean up directories which are used for  temporary  holding  space
       such as /tmp.

       When  changing directories, tmpwatch is very sensitive to possible race conditions and
       will exit with an error if one is detected. It does not follow symbolic links  in  the
       directories it's cleaning (even if a symbolic link is given as its argument), does not
       switch filesystems (including non-trivial bind mounts), skips  lost+found  directories
       owned  by  the  root user, and only removes empty directories, regular files, and sym-
       bolic links.

       By default, tmpwatch dates files by their atime (access time), not their mtime  (modi-
       fication  time).  If files aren't being removed when ls -l implies they should be, use
       ls -u to examine their atime to see if that explains the problem.

       If the --atime, --ctime or --mtime options are used in combination, the decision about
       deleting  a  file  will be based on the maximum of these times.  The --dirmtime option
       implies ignoring atime of directories, even if the --atime option is used.

       The time parameter defines the threshold for removing files.  If the file has not been
       accessed  for  time,  the  file  is  removed.   The  time argument is a number with an
       optional single-character suffix specifying the units: m for minutes, h for  hours,  d
       for days.  If no suffix is specified, time is in hours.

       Following this, one or more directories may be given for tmpwatch to clean up.

OPTIONS
        ...

You can schedule it safely with cron.

dd_wizard

---------- Post added at 10:53 AM ---------- Previous post was at 10:47 AM ----------

With an appropriate age parameter, you should be able to call it in your ~/.bash_logout, also.

dd_wizard

[scott32746]

Hello,
I do see this solved, but would like to add

May like to look at tmpwatch
$ man tmpwatch

http://prefetch.net/blog/index.php/2...with-tmpwatch/
http://www.redips.net/linux/tmpwatch-delete-files/