Files on /dev/shm/ disappear

[Antal Koós]

Hi!

I'm not an expert Debian user and would like to know which package may have the error? Openssh-server maybe?

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.

user1@debhost:~$ id
uid=1001(user1) gid=1001(user1) groups=1001(user1)
user1@debhost:~$ su -l user2
Password:  
user2@debhost:~$ id
uid=1002(user2) gid=1002(user2) groups=1002(user2)
user2@debhost:~$ touch /dev/shm/foofoo
user2@debhost:~$ ls /dev/shm/foofoo
/dev/shm/foofoo

On the other host:

kantal@Olympus:~$ touch barbar
kantal@Olympus:~$ scp barbar user2@debhost:
user2@debhost's password:  
barbar                     100%    0     0.0KB/s   00:00

Back to the 'debhost':

user2@debhost:~$ ls barbar  
barbar
user2@debhost:~$ ls /dev/shm/foofoo
ls: cannot access '/dev/shm/foofoo': No such file or directory
user2@debhost:~$ uname -a
Linux debhost 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-0
1-18) x86_64 GNU/Linux
user2@debhost:~$ cat /etc/issue
Debian GNU/Linux 11 \n \l

Thanks,

 kantal

[Greg Wooledge]

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% 21 65.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.

[Andy Smith]

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

[Andy Smith]

On Wed, Mar 02, 2022 at 02:28:07PM +0000, 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.

[David Wright]

On Wed 02 Mar 2022 at 14:28:07 (+0000), 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.