#2114 Issue closed: mount /dev/shm by default in recovery image?¶

Labels: enhancement, no-issue-activity

abbbi opened issue at 2019-04-10 14:58:¶

hi,

we from SEP ship a component that implements our own SSH backend. This component fails to correctly work if /dev/shm is not mounted in the recovery image, for example:

  File "/usr/local/sesam-ssl-101/lib/python2.7/threading.py", line 754, in run
  File "sm_sshd.py", line 387, in handle_connection_thread
  File "/usr/local/sesam-ssl-101/lib/python2.7/multiprocessing/__init__.py", line 218, in Queue
  File "/usr/local/sesam-ssl-101/lib/python2.7/multiprocessing/queues.py", line 63, in __init__
  File "/usr/local/sesam-ssl-101/lib/python2.7/multiprocessing/synchronize.py", line 147, in __init__
  File "/usr/local/sesam-ssl-101/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__
OSError: [Errno 38] Function not implemented

after mounting /dev/shm, the needed python libraries work:

mount -t tmpfs none /dev/shm/ -o rw,nosuid,nodev,noexec

so question: would it be also useful for other components in the recovery image to mount /dev/shm by default to make components depending on shared memory work out of the box?

abbbi commented at 2019-04-10 17:42:¶

As a note: this only seems to happen on systems not using Systemd (SLES11 for example) as systemd by default does mount /dev/shm with defaults.

schlomo commented at 2019-04-10 19:52:¶

I think that it is a good idea to enable shared memory by default and don't see the harm in it.

github-actions commented at 2020-06-30 01:33:¶

Stale issue message

---

[Export of Github issue for rear/rear.]