GlobaLeaks
GlobaLeaks copied to clipboard
No such file or directory: '/dev/shm/globaleaks'
What version of GlobaLeaks are you using?
GlobaLeaks version: 4.13.18 Database version: 66
What browser(s) are you seeing the problem on?
All
What operating system(s) are you seeing the problem on?
Linux
Describe the issue
Alerts stated that /dev/shm/globaleaks
was missing. Restarting this service re-creates it, but another alert at midnight UTC was noted. It looks like /dev/shm/
was cleared.
We first noticed this issue when updating from globaleaks 4.10.18 to 4.13.15 on Ubuntu 20.04.6 LTS. This deployment was first installed in 2021.
Let me know if you need more information.
2023-11-16 00:00:00+0000 [-] [E] Job Cleaning died with runtime -1.0000 [low: -1.0000, high: -1.0000]
2023-11-16 00:00:00+0000 [-] Traceback (most recent call last):
2023-11-16 00:00:00+0000 [-] File "/usr/lib/python3/dist-packages/globaleaks/jobs/job.py", line 49, in run
2023-11-16 00:00:00+0000 [-] yield self.operation()
2023-11-16 00:00:00+0000 [-] File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418, in _inlineCallbacks
2023-11-16 00:00:00+0000 [-] result = g.send(result)
2023-11-16 00:00:00+0000 [-] File "/usr/lib/python3/dist-packages/globaleaks/jobs/cleaning.py", line 155, in operation
2023-11-16 00:00:00+0000 [-] self.perform_secure_deletion_of_temporary_files()
2023-11-16 00:00:00+0000 [-] File "/usr/lib/python3/dist-packages/globaleaks/jobs/cleaning.py", line 121, in perform_secure_deletion_of_temporary_files
2023-11-16 00:00:00+0000 [-] for f in os.listdir(self.state.settings.ramdisk_path):
2023-11-16 00:00:00+0000 [-] FileNotFoundError: [Errno 2] No such file or directory: '/dev/shm/globaleaks'
2023-11-16 00:00:00+0000 [-] [E] Unhandled exception raised:
2023-11-16 00:00:00+0000 [-] [E] FileNotFoundError File not found.\n\nTraceback (most recent call last):\n\n File "/usr/lib/python3/dist-packages/globaleaks/jobs/job.py", line 49, in run\n yield self.operation()\n\n File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418, in _inlineCallbacks\n result = g.send(result)\n\n File "/usr/lib/python3/dist-packages/globaleaks/jobs/cleaning.py", line 155, in operation\n self.perform_secure_deletion_of_temporary_files()\n\n File "/usr/lib/python3/dist-packages/globaleaks/jobs/cleaning.py", line 121, in perform_secure_deletion_of_temporary_files\n for f in os.listdir(self.state.settings.ramdisk_path):\n\nFileNotFoundError: [Errno 2] No such file or directory: '/dev/shm/globaleaks'\n
2023-11-16 00:00:09+0000 [-] Starting factory <twisted.mail.smtp.ESMTPSenderFactory object at .....>
...
Proposed solution
We were able to solve this by setting RemoveIPC=no
in /etc/systemd/logind.conf
and verifying that the user may linger via sudo loginctl enable-linger globaleaks
.
My understanding is that RemoveIPC
is not necessary if the user running the service is a system user, so changing logind.conf
may be superfluous.
Foolish mistake of me to leave the title.
Additionally, it does look like the globaleaks user is correctly added as a system user from the commit. We could attribute this to user error, as I did not deploy it either.
Thank you @BaderSZ you reporting and analysis was very helpful.
We are noticing this on some setups but we were not aware of this behaviour of systemd.
It is true that we create the user as system user, but since a while we are enforgin the uuid to be 1337 to have a known id. (it was needed for docker: https://github.com/globaleaks/GlobaLeaks/blob/main/docker/Dockerfile#L18C1-L20C10) If seems that linux by default considers system users only users <=1000.
@rglauco @gianlucagilardi: do you think it is really needed to have a fixed UID?
We have either two options:
- makes the system take one availabile UID below < 1000; this would be the safe option as the operation system will never fail assigning one that is free
- chose a number belore <= 1000 that reasonably is not used in standard setups of ubuntu/debian: e.g. 842.
I would actually prefer to let the operating system choose.
* makes the system take one availabile UID below < 1000; this would be the safe option as the operation system will never fail assigning one that is free * chose a number belore <= 1000 that reasonably is not used in standard setups of ubuntu/debian: e.g. 888.
I would actually prefer to let the operating system choose.
I'll agree with you on this. The UID range is defined in /etc/login.defs
and the range SYS_UID_MIN
- SYS_UID_MAX
may not necessarily be < 1000. SystemD also seems to have had bugs in the past with this. [1] [2]
In the meantime we look a solution for docker rootless i will remove the explicit UID assignment.
Users that experience the issue could fix their system with:
systemctl stop globaleaks
usermod globaleaks 888
systemctl start globaleaks
this command assumes there is no system user with id 888.
Closing since the bug was fixed and no issues are known on this matter in current release 4.15.5