PDA

View Full Version : clean /tmp safely at shutdown



egcp
20th January 2010, 06:34 PM
Hi,

I have been using this tip at http://fedoranews.org/krishnan/tips/tip014.shtml (see below) to delete the temporary files created in /tmp for quite a few Fedora versions. But, I just found out that it does not work in F12. Is there are reason why it doesn't work?

Thanks,
egcp
----
2004-01-19 Fedora Tips #14:
If you want to delete all files in /tmp directory easily without deleting the directory itself is by giving the following command

rm -rf /tmp/.??* /tmp/*

You can put this into /etc/rc.d/init.d/syslog into the "stop)" section. This will clean up /tmp at every shutdown and keep your disk clean. Please note that you should not run this command when X-Windows is running. - submitted by Krishnan Subramanian.
--

aleph
21st January 2010, 04:19 AM
The "tip" was so ugly a hack. It was ugly in so many levels that I don't feel like listing them all.

By default there's a cronjob "tmpwatch" that periodically nukes the contents in /tmp.

If the daily cleanup isn't (paranoid) enough, just mount the /tmp directory as in-memory tmpfs.

1) Manually nuke the contents in there;

2) Edit /etc/fstab. Add this line to the file:


none /tmp tmpfs noexec,uid=0,gid=0,mode=1777,size=64m 0 0

You may alter the size parameter to fit in your RAM usage. If left unspecified, the max size for /tmp will be half your physical RAM, which is usually not a good idea anyway. Just don't make it too small.

3) Mount it: mount -a.

Now the whole /tmp directory will reside in the RAM, never hitting the disk (unless swapping kicks in). After a poweroff, the contents are automatically nuked.

I have written another guide about tmpfs usage. You may find it interesting.
http://forums.fedoraforum.org/showthread.php?t=232855

jimbux
7th February 2010, 04:06 AM
Hey Aleph - thanks for the useful info. I've been thinking about this issue lately and have a further question.

I checked into your suggestions - and I totally trust you that the "tip" is an ugly hack that should be avoided but I would love an explanation of why - since it seems like a safe idea. (I use F9 - but assume this will change someday.)

I don't want to run tmpwatch in general since I don't know if it's safe (some program could be running as BG process - but not happen to be called upon for an indeterminately long span of time) - PLUS I dont' want to suck up my memory with /tmp usage ... BUT I still would like to have /tmp cleaned out when the computer does a reboot cycle.

So... what's the rule for /tmp? I would think that when booting - there's a point at which /tmp can be totally wiped clean. What is that point - when shutting down or coming up? No program should be able to assume that the contents of /tmp survive reboots right? Therefor I would expect that no contents of /tmp should be older than uptime. Right?

So - if I'm right - what's the best way to clean /tmp on a reboot cycle?

James.

aleph
7th February 2010, 04:59 AM
Why the hack was ugly:
1. If you want your own initscript, write one. Don't stick some commands in an existing initscript installed by a package.
2. If one really want to use such a hack, it should be kept secret, because publicizing it on the Internet makes the hack double plus ugly :D
3. The hack will remove EVERYTHING removable in the /tmp directory, including the ones carefully excluded by the stock tmpwatch cronjob. (see: /etc/cron.daily/tmpwatch). That's why the author said that "Please note that you should not run this command when X-Windows is running".

WRT tmpwatch:
It has been part of a default install for quite a long time. I haven't run into problems, but YMMV. The default retention period for /tmp is ten days and 30 days for /var/tmp. Date is calculated by comparing the current date and the last access time (atime) of the files in /tmp. Only regular files and empty directories are removed, while named pipes and sockets are kept untouched. In general, it is arguably safer than the hack, I guess.

And yes, any long-running process expecting persistent objects in /tmp is insane and should be replaced by a better competitive.

The "rules" for /tmp has been laid out by the POSIX standard (http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap10.html)

/tmp
A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application.
And the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES):


/tmp : Temporary files
Purpose

The /tmp directory must be made available for programs that require temporary files.

Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

Rationale


IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section.

Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.


It is quite possible that a process runs much longer than the 10-day retention limit, and it is perfectly standard-compliant to "expect" its temp files to stay during the process' lifetime which is longer than the retention limit. But in practice, anyone releasing a program like this should be re-educated and keep on copying the dictionary definition of "temporary" for the rest of his life. :D

jimbux
7th February 2010, 05:39 PM
Thanks Aleph for your (as usual) great explanation and thoughtful response. I hunted around my system and found an existing tmpwatch cron job which has been instructive to look at.

I think I want to find a way to blow away the contents of /tmp upon boot for all my machines - since that seems a good policy. Not sure exactly where/how I should do this - and I don't want to ask you for public advice on that in fear of violating your "ugly hack" principle #2! ...but I'm tempted. :)

kyryder
7th February 2010, 06:19 PM
Thanks Aleph for your (as usual) great explanation and thoughtful response. I hunted around my system and found an existing tmpwatch cron job which has been instructive to look at.

I think I want to find a way to blow away the contents of /tmp upon boot for all my machines - since that seems a good policy. Not sure exactly where/how I should do this - and I don't want to ask you for public advice on that in fear of violating your "ugly hack" principle #2! ...but I'm tempted. :)

Hello,

Here is a link to a thread that will give you the info on how to: http://forums.fedoraforum.org/showthread.php?p=1324545#post1324545

jimbux
7th February 2010, 09:02 PM
Thanks for the helpful link KyRy.

aleph
8th February 2010, 04:16 AM
Thanks Aleph for your (as usual) great explanation and thoughtful response. I hunted around my system and found an existing tmpwatch cron job which has been instructive to look at.

I think I want to find a way to blow away the contents of /tmp upon boot for all my machines - since that seems a good policy. Not sure exactly where/how I should do this - and I don't want to ask you for public advice on that in fear of violating your "ugly hack" principle #2! ...but I'm tempted. :)

If my rule#2 had been actually implemented and enforced, over 90% of the Internet would have been annihilated. :D

The most direct way of doing this is to use tmpfs and keep everything in RAM. However, this reduces the available RAM for other purposes.

You can also write your own script and stick it into the file /etc/rc.d/rc.local so that it is executed when the machine boots.
Here's an example taken directly from the cronjob with some slight modification.


flags=-umcs
/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
-x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
-X '/tmp/hsperfdata_*' 0 /tmp


The only two modifications are:
1. setting the retention limit to zero, so everything (except special files and excluded files) in the /tmp directory will be considered obsolete and removed.
2. by giving tmpwatch the "-s" flat, it will try to use /sbin/fuser to determine whether a file is in use by some process, thus prevent it from being removed.

asonjay
28th March 2012, 08:17 PM
...You can put this into /etc/rc.d/init.d/syslog into the "stop)" section...
--

What package installs syslog?

DBelton
28th March 2012, 08:28 PM
IF you are running F15 or newer, it is being done by systemd now, and the above instructions are pretty much useless.

The best option with systemd is to mount /tmp as tmpfs or use tmpwatch

Edit:

If you wish to use the option of mounting /tmp as tmpfs...

1: delete everything in /tmp (all hidden file, directories, etc...)

2: add to your /etc/fstab


tmpfs /tmp tmpfs defaults 0 0

3: reboot

jpollard
28th March 2012, 08:39 PM
It also depends on what you use /tmp for.

In some cases, you actually don't want to wipe it out - large project compilations may go to pot (depending on where and how you compile).

Some applications use /tmp for data to pass from process to process. Rebooting would destroy that data preventing them from resuming. (Places I have worked made a "/scratch" filesystem for that - and put quotas on it. Anyone that put semi-permanent data in /tmp got what they deserved.)

A few places would rename the /tmp directory and create a new one - and start a "rm -rf /old-tmp" because it could take a long time to clean out. An alternative was to have /tmp on a partition - and do a mkfs just before mounting it....

Using tmpfs in a system tight on memory (or big on users) is a way to cause the system to hang. Doing so assumes you have a bigger swap so that the tmpfs mount can be paged out... The advantage that tmpfs has is that it is always clean when the system boots.

tmpwatch is safer, and allows a configurable time to define when a file is to be deleted.

asonjay
28th March 2012, 09:37 PM
...2) Edit /etc/fstab. Add this line to the file:


none /tmp tmpfs noexec,uid=0,gid=0,mode=1777,size=64m 0 0

You may alter the size parameter to fit in your RAM usage. If left unspecified, the max size for /tmp will be half your physical RAM, which is usually not a good idea anyway. Just don't make it too small...

Anyone know how this could be done from a fresh install? Seems like anaconda is very limited in the way it allows partitioning and advanced partitioning I find often causes anaconda to crash.

Gareth Jones
29th March 2012, 05:45 PM
Rebooting would destroy that data preventing them from resuming. (Places I have worked made a "/scratch" filesystem for that - and put quotas on it. Anyone that put semi-permanent data in /tmp got what they deserved.)

As I remember the FHS, /var/tmp is the place for "persistent" temporary files. Software which relies on /tmp surviving reboots is not standards-compliant.

That said, I do think it's untidy in a potentially long-uptime system such as Linux that reboots should be relied upon for routine cleaning. Unfortunately it's difficult for software which isn't using temporary files to judge whether it's safe to remove them or not. Really, leaving unused files in /tmp should be regarded in the same way memory leaks are as a bug that should be fixed.

---------- Post added at 05:45 PM ---------- Previous post was at 05:42 PM ----------


Anyone know how this could be done from a fresh install?

When the new /run directory was being discussed by developers, there was mention of using a /tmp->/run/tmp symlink for /tmp on tmpfs. Presumably this needs support from the init system to create the /run/tmp mount-point after mounting /run, so I've no idea whether Fedora/Systemd supports that yet.

Either way, it'd be nice to have /tmp on tmpfs support from install...

DBelton
29th March 2012, 06:08 PM
It also depends on what you use /tmp for.

In some cases, you actually don't want to wipe it out - large project compilations may go to pot (depending on where and how you compile).

Some applications use /tmp for data to pass from process to process. Rebooting would destroy that data preventing them from resuming. (Places I have worked made a "/scratch" filesystem for that - and put quotas on it. Anyone that put semi-permanent data in /tmp got what they deserved.)

A few places would rename the /tmp directory and create a new one - and start a "rm -rf /old-tmp" because it could take a long time to clean out. An alternative was to have /tmp on a partition - and do a mkfs just before mounting it....

Using tmpfs in a system tight on memory (or big on users) is a way to cause the system to hang. Doing so assumes you have a bigger swap so that the tmpfs mount can be paged out... The advantage that tmpfs has is that it is always clean when the system boots.

tmpwatch is safer, and allows a configurable time to define when a file is to be deleted.


If the application expects data to be passed from run to run, then it should not be using /tmp. It should use /var/tmp instead.

The recommendation of FHS is to delete /tmp on every boot, although it doesn't get deleted, no application should expect /tmp to be preserved.

tmpwatch is a good alternative, but there is one caveat. If you mount using noatime, then tmpwatch doesn't work properly. (I wouldn't mount the root filesystem noatime anyway, and /tmp is part of it by default n Fedora now)

jpollard
29th March 2012, 07:51 PM
Use of /var/tmp depends on the site - Many have that as a symbolic link to /tmp.

Though use of /var/tmp is better than /tmp.

Most of the reason for a /scratch is for allowing 10s of TBs for scratch. And that is a bit tricky for /var/tmp (mounts should work, but some things get funny when files get covered by a mount while they use it.) I have also used mounts for /tmp just to be able to have decent quota controls on it (which is why /var/tmp became a symbolic link). I seem to remember solaris made /var/tmp a symbolic link (or was that /tmp a symbolic link to /var/tmp? Its been a while)

Management preferred the /scratch approach so that general documentation would not be "inaccurate", and local documentation would direct users to /scratch.

stevea
29th March 2012, 08:31 PM
DB' - I'm afraid "don't feed the troll" now applies to JPollard. In case it's not obvious ALL of his recent posts contain negativity, anti-linux FUD and gross misinformation.


It also depends on what you use /tmp for.

In some cases, you actually don't want to wipe it out - large project compilations may go to pot (depending on where and how you compile).

Right :C - deleting /tmp at shutdown or deleting 10+day old non-session files /tmp interferes with compiles ??? For anyone else I'd say "you must be joking". In your case 'you must be trolling' is more appropriate.


Some applications use /tmp for data to pass from process to process. Rebooting would destroy that data preventing them from resuming.

Depending on /tmp contents across reboots is stupid and wrongheaded. So you are suggesting the OP should config his system to accommodate hypothetical very badly written apps that mostly don't exist. This suggestion is itself inane and should never have been posted. It's FUD from our resident nattering nabob of negativism.


Using tmpfs in a system tight on memory (or big on users) is a way to cause the system to hang.
No it doesn't cause the system to "hang" - that is pure anti-linux FUD and MISINFORMATION; just another part of your "linux is awful" campaign. If there is insufficient /tmp or insufficient swap - then of course processes fail. The system doesn't 'hang'.

If you can show otherwise then provide a link to your bugzilla entry - otherwise stop the lies !

I am posting this from an F16 system I rigged with

[stevea@lycoperdon Desktop]$ cat /etc/fstab | grep /tmp
none /tmp tmpfs defaults,size=1k 0 0

# but a single page is 4kb so ...

[stevea@lycoperdon Desktop]$ mount | grep /tmp
none on /tmp type tmpfs (rw,relatime,size=4k)

The bootup was absolutely clean. The kdm failed over to gdm, and I have a fallback Gnome3 desktop running.
ssh works, firefox with 5 tabs works, the NFS mounts work. Untarring a massive tarball works. Running ./configure for a package results in the obvious error ...
./configure: line 44: cannot create temp file for here-document: No space left on device
gnome-terminal back-scrolling fails.
Attemping to open a web pdf shows a similarly clear message about the problem.


No - lack of /tmp doesn't cause a system hang.
Lack of swap doesn't either.

jpollard
29th March 2012, 10:04 PM
Right :C - deleting /tmp at shutdown or deleting 10+day old non-session files /tmp interferes with compiles ??? For anyone else I'd say "you must be joking". In your case 'you must be trolling' is more appropriate.


I said WIPE IT OUT. Not delete old things.



Depending on /tmp contents across reboots is stupid and wrongheaded. So you are suggesting the OP should config his system to accommodate hypothetical very badly written apps that mostly don't exist. This suggestion is itself inane and should never have been posted. It's FUD from our resident nattering nabob of negativism.

Never said it was smart - just that it is done.


No it doesn't cause the system to "hang" - that is pure anti-linux FUD and MISINFORMATION; just another part of your "linux is awful" campaign. If there is insufficient /tmp or insufficient swap - then of course processes fail. The system doesn't 'hang'.

If you can show otherwise then provide a link to your bugzilla entry - otherwise stop the lies !


When the keyboard doesn't respond...
When the mouse doesn't respond...
When the network doesn't respond...

What do YOU call it?



I am posting this from an F16 system I rigged with


The bootup was absolutely clean. The kdm failed over to gdm, and I have a fallback Gnome3 desktop running.
ssh works, firefox with 5 tabs works, the NFS mounts work. Untarring a massive tarball works. Running ./configure for a package results in the obvious error ...
./configure: line 44: cannot create temp file for here-document: No space left on device
gnome-terminal back-scrolling fails.
Attemping to open a web pdf shows a similarly clear message about the problem.


No - lack of /tmp doesn't cause a system hang.
Lack of swap doesn't either.

Since you don't seem to understand, the OOM killer cannot detect all conditions. It makes the assumption that the system is not that dynamic - runaway processes can and will use up resources faster than they can be cleaned up or detected.

It doesn't happen that often, but it does happen.
I've still failed at being able to reproduce the condition...
Though it looks like running PovRay with lots of threads and a HUGE number of objects seems to do it.

stevea
29th March 2012, 10:48 PM
I said WIPE IT OUT. Not delete old things.

Deleting /etc will ruin your install too - SO WHAT ?
NO ONE was talking about WIPING /etc nor /tmp except at shutdown - so it's pure non sequitur FUD.




Never said it was smart - just that it is done.

Where ? Show a real-world example form the repo or even sourceforge. No - it's virtualy never done and no one should care about software so carelessly written. Show evidence or admit you are talking through your hat. The fact that you imagine people should configure their systems to prevent imaginary bad software from failing is a problem. You aren't helping any linux user - are are creating FUD.



When the keyboard doesn't respond...
When the mouse doesn't respond...
When the network doesn't respond...

What do YOU call it?

None of those actually happen - so again you are creating IMAGINARY fears.
The KB&Mouse interfaces do not use /tmp.
The network doesn't use /tmp
X11 clearly does need minimal /tmp

Yes - some APPS like the X11-server fail whenever there is a required resource shortage - that is not a system hang.


Since you don't seem to understand, the OOM killer cannot detect all conditions. It makes the assumption that the system is not that dynamic - runaway processes can and will use up resources faster than they can be cleaned up or detected.

You're the loon who doesn't understand. OOM killer harvests processes according to a policy that is settable. Processes killed DOES NOT equal "system hang". None of this discussion is about "runaway processes" so you are trying to change the goalpost. Yes processes including those started in systemd (or sysvinit may be reaped. BUT you are constantly whining about systemd despite he fact it creates cgroup containers that restrain any runaway processes from hogging resources.

Stop the overblown fear-mongering - none of your concerns are realistic.


It doesn't happen that often, but it does happen.

No it doesn't. Show an example or a bugzilla report.



I've still failed at being able to reproduce the condition...
Though it looks like running PovRay with lots of threads and a HUGE number of objects seems to do it.

Do what ? Be specific. Did the system hang ? Post the method.

If PovRay is abusing mem then OOM kills *something* nuless cgroup poicy stops it first. That's not a system hang. Al the other cgroups & services are intact and running - right ?

---------- Post added at 05:48 PM ---------- Previous post was at 05:46 PM ----------


I guess this will give you something to kvetch about for 2013.https://fedoraproject.org/wiki/Features/tmp-on-tmpfs

Gareth Jones
30th March 2012, 12:01 AM
I guess this will give you something to kvetch about for 2013.https://fedoraproject.org/wiki/Features/tmp-on-tmpfs

Interesting. I guess they've changed their opinions since the /tmp->/run/tmp discussion then.

---------- Post added 30th March 2012 at 12:01 AM ---------- Previous post was 29th March 2012 at 11:42 PM ----------


Use of /var/tmp depends on the site - Many have that as a symbolic link to /tmp.

[...]

Management preferred the /scratch approach so that general documentation would not be "inaccurate", and local documentation would direct users to /scratch.

This is all fine and good as long as the distribution developers or the system administrator (you?) understand and take responsibility for the set-up, which it sounds like occurred in your case. It shouldn't affect the expectations of (non-local) software in terms of temporary file storage however, which should default to following the relevant standards. Failing to do so would be a bug, and presumably the linked F18 /tmp-on-tmpfs feature will help weed-out and fix such bugs.

I've manually cleaned /tmp from files left by "leaky" programs on Fedora by logging on to a virtual terminal and removing the files immediately before rebooting. It's never been a problem. But I don't trust things like tmpwatch to remove files during normal runtime, based purely on atime!

DBelton
30th March 2012, 05:18 AM
I've been running with /tmp as tmpfs here for quite awhile anyway.

And if the use of /var/tmp depends o the site, tehn the sites that don't use it aren't adhering to FHS.



/var/tmp : Temporary files preserved between system reboots
Purpose

The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.

Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.


And also from the FHS:



/tmp : Temporary files
Purpose

The /tmp directory must be made available for programs that require temporary files.

Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

vallimar
30th March 2012, 04:10 PM
Just as an aside, I took a slightly different approach with my F17 system.
Instead of making /tmp yet another tmpfs instance, I made it a bind mount
to the already existing generic tmpfs mount /dev/shm. Haven't noticed any
problems with this approach thus far.


#
# /etc/fstab
[...]
/dev/shm /tmp none bind

jpollard
30th March 2012, 10:33 PM
That will depend on how much shared memory you use.

If none, then it won't be a problem.

If a lot... you may run out and get odd application failures.

Especially if they dynamically generate segements.

One application that uses shared memory is pulse audio... On my system there are two users:


$ ls -l /dev/shm
total 2952
-r--------. 1 gdm gdm 67108904 Mar 30 16:09 pulse-shm-1976080014
-r--------. 1 gdm gdm 67108904 Mar 30 10:43 pulse-shm-2119770891
-r--------. 1 pam pam 67108904 Mar 30 07:21 pulse-shm-2547428243
-r--------. 1 pam pam 67108904 Mar 30 07:21 pulse-shm-302791272
-r--------. 1 gdm gdm 67108904 Mar 30 10:43 pulse-shm-3078338420
-r--------. 1 jesse jesse 67108904 Mar 30 18:03 pulse-shm-3597110546
-r--------. 1 jesse jesse 67108904 Mar 30 17:56 pulse-shm-3759464687

So it adds up...

vallimar
31st March 2012, 10:58 PM
For my usage, it's not an issue. I would wager most people won't have a problem
unless they are on a low memory system.

marko
31st March 2012, 11:51 PM
That will depend on how much shared memory you use.

If none, then it won't be a problem.

If a lot... you may run out and get odd application failures.

Especially if they dynamically generate segements.

One application that uses shared memory is pulse audio... On my system there are two users:


$ ls -l /dev/shm
total 2952
-r--------. 1 gdm gdm 67108904 Mar 30 16:09 pulse-shm-1976080014
-r--------. 1 gdm gdm 67108904 Mar 30 10:43 pulse-shm-2119770891
-r--------. 1 pam pam 67108904 Mar 30 07:21 pulse-shm-2547428243
-r--------. 1 pam pam 67108904 Mar 30 07:21 pulse-shm-302791272
-r--------. 1 gdm gdm 67108904 Mar 30 10:43 pulse-shm-3078338420
-r--------. 1 jesse jesse 67108904 Mar 30 18:03 pulse-shm-3597110546
-r--------. 1 jesse jesse 67108904 Mar 30 17:56 pulse-shm-3759464687
So it adds up...

if you look at those pulse-shm dev files with ls -s (which tells ls to show the actually allocated space) you get a much smaller number, more like 4kB.
I suspect those are kind of like sparse files on disk, they don't actually use that much space?

mmix
1st April 2012, 12:02 AM
Cleaning Up Your /tmp...The Safe Way
http://linuxgazette.net/issue18/tmp.html

cleantmp perl script:
http://linuxgazette.net/issue18/cleantmp.html

HTH

dd_wizard
1st April 2012, 12:39 AM
The last few posts have made me wonder... These outputs are on my F17 install which still has /tmp on the hard drive.


$ ls -hl /dev/shm
total 3.0M
-r--------. 1 gene gene 65M Mar 31 16:19 pulse-shm-1276800931
-r--------. 1 gdm gdm 65M Mar 31 15:50 pulse-shm-1341714612
...

$ ls -hl /run
total 84K
drwxrwxr-x. 2 root backuppc 40 Mar 31 15:50 BackupPC
drwxr-xr-x. 2 root root 60 Mar 31 15:50 ConsoleKit
drwxr-xr-x. 2 root root 80 Mar 31 15:50 abrt
-rw-r--r--. 1 root root 4 Mar 31 15:50 abrtd.pid
-rw-r--r--. 1 root root 4 Mar 31 15:50 acpid.pid
srw-rw-rw-. 1 root root 0 Mar 31 15:50 acpid.socket
-rw-r--r--. 1 root root 4 Mar 31 15:50 atd.pid
...

$ df -h
Filesystem Size Used Avail Use% Mounted on
...
tmpfs 998M 3.0M 995M 1% /dev/shm
tmpfs 998M 1.5M 996M 1% /run
...

$ du -h /dev/shm/*
1.3M /dev/shm/pulse-shm-1276800931
4.0K /dev/shm/pulse-shm-1341714612
...

Any idea what is being displayed in the size field of "ls -hl /dev/shm?" It's not the file or file system size.

dd_wizard

jpollard
1st April 2012, 02:53 PM
I believe those are shared memory segments used to pass relatively large amounts of data quickly between processes.

/dev/shm is not disk - it is a tmpfs, and is memory resident only.

/run is the same way - memory resident only.