Guess they could provide 'no space left on device' error, however it's not to say that they should fix your low /dev/shm, which is typically mounted as tmpfs (which by default has max size of 1/2 RAM).
If you see some 'leftovers', you should probably report them in separate bugs (one per each game).
Well my /dev/shm is so small so that leftovers won't end up taking half of my ram. And if you add-up the total default size of all tmpfs, it's about 150%-200% of the RAM.
Leftovers in tmpfs typically are not a big deal (asuming you have swap), since tmpfs contents are typically swapped out first.
Especially if these are unused for longer periods of time.
If you are not useing swap then it might be an issue (though I'm not defending 'leftover' files in /dev/shm).
It all depends on how many programs leave leftovers there and how often you reboot. I normally don't reboot for weeks and certainly my swap isn't 2 times as big as my RAM.
I can verify this is still a problem as of the date of this comment (8 years later!!!). I will run steam, play a game, close steam. Each time it creates about 10 shm-entries, each being around 11M in size, so around 100M each time. Since I will play games a few times per day this quickly will accumulate to rather large sums. Right now steam have allocated 5.6G in about 10 days. Please deallocate system resources upon exiting the steam client.
Edit: I think one possible solution would be to not use the naming scheme with random filenames, if it used the same filenames it would reuse the wasted resources at least.
I tried to google how to find an app which creates but doesn't delete files from /dev/shm and I finally found it was steam.
After each opening and closing steam 2 shm entries are leaked - u${user}-Shm_${hash} both 10485776 bytes.
Both of them are used by ./steamwebhelper(most shm entries are used by /.steam/debian-installation/ubuntu12_32/steam, but they are not leaked)
There are also 2 constant entries which are leaked once after first start stop and reused by next runs: u${user}-ValveIPCSharedObj-Steam and small u${user}-Shm_${hash} where hash is the same each time(even after deleting it's created with the same hash). hash of constantly leaked-once file is 1253xxxx(I'm not sure if it depends on user, last 4 hex digits are removed by me)
You really think they will ever fix this?
can we be met halfway and at least put all this crap into its own pile (directory) to make cleanup easier?
Same here. I had an issue of RAM filling up with long uptimes and it took me a while to realize that it was the shared memory, more specifically /dev/shm, and that steam/cs2 is responsible for it.
For now I'll just add some rm's to my steam startup command, but yeah Valve it's impolite not to clean up after yourselves...
You really think they will ever fix this?
It took them 10 years and a major upgrade to finally fix a simple keyboard mapping issue in Source on Linux... there's still hope... :facepalm:
It's 2024. Still not fixed.
I found these because I symlink some directories like ~/.local to /dev/shm/xdg/.local which points back to ~/xdg/@local/$HOSTNAME - so that things in ~/.local end up segregated by which host they're supposed to be local on (since my home directory is NFS mounted to multiple hosts at home, and it's not going to make them fast on other hosts). Too bad this isn't an old Apollo UNIX workstation where environment variables were actually interpreted in symlinks - it would have been a perfect fit for my problem.
Anyway... So when looking at /dev/shm/ itself, I noticed all these u$uid-Shm_$hash files in various (0, 4, 8, 516, 1028, 2048, 16388, 25604, with most bytes being in the 20 x 16388 files) but repeated sizes going back for a month and a half, and then when I run "lsof | grep /dev/shm" I find that there are other files in use in this directory, but not listed, so I assume they were created, rendezvoused on, and then unlinked to automate cleanup. Many are from fossilize (texture processing, I think), some /dev/shm/.com.valvesoftware.Steam.$hash files, and a mysterious /dev/shm/#9035
Both points in the other posts are spot on, though
That latter part is a bit tricky. I can understand how devs would be reluctant to put a directory in here, given questions around whether deleting a directory containing open files and then recreating it could expose a filesystem bug, etc, etc. It seems likely that the /dev/shm/-whatever-/ could be too easily left as trash. But in that case, the .com.valvesoftware.-stuff- files are solid approach, and these annoying u$uid-Shm_$hash files are definitely the WRONG approach.
So, maybe I'll check back in 2030 or something....
$ sudo lsof /dev/shm/u1000-*
lsof: WARNING: can't stat() fuse.Nextcloud-3.13.1-x86_64.AppImage file system /tmp/user/1000/.mount_nextclJVJZNb
Output information may be incomplete.
lsof: WARNING: can't stat() fuse.Linphone-5.2.6.AppImage file system /tmp/user/1000/.mount_linphoGJNhbr
Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
steam 25936 quix0r mem REG 0,28 26214416 470 /dev/shm/u1000-Shm_bb04df82
steam 25936 quix0r mem REG 0,28 26214416 471 /dev/shm/u1000-Shm_a269467c
steam 25936 quix0r mem REG 0,28 1048592 25 /dev/shm/u1000-Shm_3c3a3c3d
steam 25936 quix0r mem REG 0,28 669120 459 /dev/shm/u1000-Shm_671c2a99
steam 25936 quix0r mem REG 0,28 519488 458 /dev/shm/u1000-Shm_fe20b6d7
steam 25936 quix0r mem REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steam 25936 quix0r mem REG 0,28 131392 460 /dev/shm/u1000-Shm_c4fbc703
steam 25936 quix0r mem REG 0,28 126272 457 /dev/shm/u1000-Shm_c9edbd50
steam 25936 quix0r mem REG 0,28 1040 236 /dev/shm/u1000-Shm_125376fc
steam 25936 quix0r mem REG 0,28 1040 20 /dev/shm/u1000-Shm_9b59e709
steam 25936 quix0r 36u REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steam 25936 quix0r 42u REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steam 25936 quix0r 62u REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steam 25936 quix0r 63u REG 0,28 1040 20 /dev/shm/u1000-Shm_9b59e709
steam 25936 quix0r 65u REG 0,28 126272 457 /dev/shm/u1000-Shm_c9edbd50
steam 25936 quix0r 66u REG 0,28 519488 458 /dev/shm/u1000-Shm_fe20b6d7
steam 25936 quix0r 67u REG 0,28 669120 459 /dev/shm/u1000-Shm_671c2a99
steam 25936 quix0r 68u REG 0,28 131392 460 /dev/shm/u1000-Shm_c4fbc703
steam 25936 quix0r 69u REG 0,28 1048592 25 /dev/shm/u1000-Shm_3c3a3c3d
steam 25936 quix0r 83u REG 0,28 669120 459 /dev/shm/u1000-Shm_671c2a99
steam 25936 quix0r 84u REG 0,28 126272 457 /dev/shm/u1000-Shm_c9edbd50
steam 25936 quix0r 85u REG 0,28 519488 458 /dev/shm/u1000-Shm_fe20b6d7
steam 25936 quix0r 87u REG 0,28 131392 460 /dev/shm/u1000-Shm_c4fbc703
steam 25936 quix0r 88u REG 0,28 1048592 25 /dev/shm/u1000-Shm_3c3a3c3d
steam 25936 quix0r 103u REG 0,28 26214416 471 /dev/shm/u1000-Shm_a269467c
steam 25936 quix0r 104u REG 0,28 26214416 470 /dev/shm/u1000-Shm_bb04df82
steam 25936 quix0r 105u REG 0,28 1040 236 /dev/shm/u1000-Shm_125376fc
steamwebh 26104 quix0r mem REG 0,28 26214416 471 /dev/shm/u1000-Shm_a269467c
steamwebh 26104 quix0r mem REG 0,28 26214416 470 /dev/shm/u1000-Shm_bb04df82
steamwebh 26104 quix0r mem REG 0,28 26214416 466 /dev/shm/u1000-Shm_ad3781b3
steamwebh 26104 quix0r mem REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steamwebh 26104 quix0r 55u REG 0,28 2097152 455 /dev/shm/u1000-ValveIPCSharedObj-Steam
steamwebh 26104 quix0r 56u REG 0,28 26214416 466 /dev/shm/u1000-Shm_ad3781b3
steamwebh 26104 quix0r 88u REG 0,28 26214416 470 /dev/shm/u1000-Shm_bb04df82
steamwebh 26104 quix0r 89u REG 0,28 26214416 471 /dev/shm/u1000-Shm_a269467c
I just started it and played only a small game (Recycling Center Simulator), suddenly I have heavy frame drops.
Nothing extracted yet.
Let me begin saying that my dev/shm is unusually small. About 60MiB.
Steam client uses to fill it and after closing leaves some garbage behind, in that directory.
That is in fact a memory leak.
The problem I meet is that some games (portal2, tf2) require more space in
/dev/shmto start and just fail silently without starting when it is not available.Providing some sort of error message would be nice. It would be even better if it could provide an indication of the actual problem.
Best