Re: Files on /dev/shm/ disappear
On Wed 02 Mar 2022 at 14:28:07 (+), Andy Smith wrote: > On Wed, Mar 02, 2022 at 07:54:53AM -0500, Greg Wooledge wrote: > > Someone who knows systemd, dbus, and all that stuff might be able to > > suggest next steps. > > I'm not really that person but yes, logind removes things from > /dev/shm for a user if it's not a system user, when that user's > session ends. Which has caused even greater confusion than this, > before: > > https://github.com/systemd/systemd/issues/4532 > > In terms of avoiding this affecting OP, firstly normal users > probably shouldn't be using /dev/shm for routine storage. I would > suggest /tmp, /var/tmp or /run/user/$UID/. AIUI though, the first two are backed by real disks on Debian (by default), and using the last one to share objects means having to fiddle with permissions because each $UID has exclusive access to their own subdirectory. (The OP involved two users.) (The reason I use /dev/shm myself is that it's B I G. But I don't suffer from the issue under discussion because I'm logged in.) Cheers, David.
Re: Files on /dev/shm/ disappear
On Wed, Mar 02, 2022 at 02:28:07PM +, Andy Smith wrote: > logind removes things from /dev/shm for a user if it's not a > system user, when that user's session ends. In case it wasn't clearly enough explained why this is happening: it clears out /dev/shm when the user's LAST session ends, but logind only considers sessions that it knows about. So when you su to a user and create something in /dev/shm that isn't a logind session. You then scp or ssh and that IS a session, and then when that session ends there are no more sessiuns, so bye bye /dev/shm content. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Files on /dev/shm/ disappear
Hello, On Wed, Mar 02, 2022 at 07:54:53AM -0500, Greg Wooledge wrote: > Someone who knows systemd, dbus, and all that stuff might be able to > suggest next steps. I'm not really that person but yes, logind removes things from /dev/shm for a user if it's not a system user, when that user's session ends. Which has caused even greater confusion than this, before: https://github.com/systemd/systemd/issues/4532 In terms of avoiding this affecting OP, firstly normal users probably shouldn't be using /dev/shm for routine storage. I would suggest /tmp, /var/tmp or /run/user/$UID/. If you don't like the cleaning up of /dev/shm then you can disable it in /etc/systemd/logind.conf: $ echo "RemoveIPC=no" | sudo tee -a /etc/systemd/logind.conf (It's already in there with its commented out default of RemoveIPC=yes) and then reboot. Or maybe there is a way to restart logind without rebooting everything. Or possibly it doesn't even need to be restarted. I have not tested this bit. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Files on /dev/shm/ disappear
On Wed, Mar 02, 2022 at 09:46:23AM +0100, Antal Koós wrote: > The symptom: > There are two users on a host 'debhost'. > I make 'su' from'user1' to 'user2', and create a file on /dev/shm. > I make 'scp' from another host for 'user2@debhost', but target is the > $HOME and not the /dev/shm. > Result: the file disapperars from /dev/shm. I am able to reproduce this, with one possibly important note: the removal is not immediate. It happens after a few seconds (less than 10 seconds in my testing). I didn't use a second computer. I just used one. "su" is also not required; I used "sudo -i -u tester" to open the session as the second user account. Here's the first window: unicorn:~$ sudo -i -u tester [sudo] password for greg: tester@unicorn:~$ touch /dev/shm/tester tester@unicorn:~$ inotifywait --monitor /dev/shm/tester Setting up watches. Watches established. /dev/shm/tester ATTRIB /dev/shm/tester DELETE_SELF Here's the second: unicorn:~$ scp foo tester@localhost: tester@localhost's password: foo 100% 2165.6KB/s 00:00 The final two lines in the first window (ATTRIB and DELETE_SELF) appeared about 8 seconds after the scp command finished. I don't know exactly what's happening here, but my initial guess is that it has something to do with session cleanup. The scp command opens a session as "tester" (or "user2"), does its work, and then terminates the session. Someone who knows systemd, dbus, and all that stuff might be able to suggest next steps.
