You are not logged in.
Hi,
I have a clean Arch install and noticed that files placed in /dev/shm do not survive a logout.
/dev/shm is a mountpoint for a tmpfs and is handled by systemd. I can also confirm this behavior in a up-to-date LXC container and an old VM (with systemd 216). Files in /tmp are persistend accross logouts...
Is there anything special about systemd's handling of shm?
Thanks and happy holidays.
Last edited by Leonid.I (2014-12-25 05:24:08)
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
Isn't this expected https://wiki.archlinux.org/index.php/Tmpfs ?
Offline
@Leonid.I: It doesn't happen here. I have tmpfiles.d placing some stuff there, and I also touched a file then logged out and back in and it was still there.
@karol logout not reboot, though I also made the same mistake somehow after just reading the thread title...
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
@Leonid.I: It doesn't happen here. I have tmpfiles.d placing some stuff there, and I also touched a file then logged out and back in and it was still there.
Hmm, do you have any processes running as your user (i.e. is your session closed when you log out)?
@karol logout not reboot, though I also made the same mistake somehow after just reading the thread title...
Sorry if the title was misleading...
I can explain why I put files in /dev/shm, but the simple way to reproduce it is:
1. Make sure things like systemd-user-sessions is not enabled.
2. Login and create a file in /dev/shm and /tmp. Both directories are managed bby systemd and are mountpoints for tmpfs. In my case, /tmp is populated, but /dev/shm is empty (so it is easy to monitor for files).
3. Log out and login again (not reboot). Verify that you get a new logind session (c3, c4, etc). The file in /dev/shm is gone, while that in /tmp persists.
I don't have any tmpfiles managing /dev/shm and "grep -i shm" against everything in /{etc,usr/lib}/tmpfiles.d comes back empty. At first, I blamed my virtual memory settings, but then tried in an old, default VM install...
EDIT: Actually, this is readily reproduced in an Arch livecd environment. I tried the 12.01 iso file in QEMU:
* For a livecd, root is logged in automatically, so switch to another tty and login as the "arch" user.
* Then, write something to a file in /dev/shm, e.g. (notice the non-root prompt)
$ dd bs=4096 count=10000 if=/dev/urandom of=/dev/shm/a.txt
* Run "findmnt -vD" to verify that some space has been consumed in /dev/shm.
* In the 1st tty (as root), confirm that a.txt exists and is readable. Monitor /dev/shm in a loop or something.
* a.txt will disappear as soon as arch logs out, assuming that was the only login of this user.
My question is what's causing this?
Last edited by Leonid.I (2014-12-25 01:09:53)
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
And... solved. It turns out that systemd-logind cleans /dev/shm upon logout. This behavior is controlled by the RemoveIPC variable in /etc/systemd/logind.conf.
Systemd... sigh.
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline