Someone is deleting my shared memory segments!

When we work with PostgreSQL under our myEnv, we regularly get shared memory segment errors. Example:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
FATAL:  could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

or we see similar messages in the PostgreSQL error log:

ERROR:  could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

Because I am a MariaDB/MySQL admin, I am not very familiar with shared memory problems (MariaDB/MySQL does not work with shared memory). Fortunately, a search on the Internet led us on the right track (source). It is noted there:

The documentation of systemd states that this only happens for non-system users. Can you check whether your “postgres” user (or whatever you are using) is a system user?

Linux System User

First I had to find out what a system user under Linux actually is. I found an answer here: What’s the difference between a normal user and a system user?.

That is not a technical difference but an organizational decision. E.g. it makes sense to show normal users in a login dialog (so that you can click them instead of having to type the user name) but it wouldn’t to show system accounts (the UIDs under which daemons and other automatic processes run) there.

The LSB standard says: User ID Ranges:

The system User IDs from 0 to 99 should be statically allocated by the system, and shall not be created by applications.
The system User IDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts using useradd.

On my Ubuntu system it looks like this:

$ grep SYS_ /etc/login.defs
#SYS_UID_MIN              100
#SYS_UID_MAX              999
#SYS_GID_MIN              100
#SYS_GID_MAX              999

This would be correct for the PostgreSQL user:

$ id postgres
uid=130(postgres) gid=142(postgres) groups=142(postgres),116(ssl-cert)

But since the PostgreSQL instance in question runs under our myEnv, that’s different:

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

So now we have two options:

1. We change SYS_UID_MAX and SYS_GID_MAX to 1001 (simple variant).
2. Or we change the UID and the GID of our user dba to less than 1000.

Simple variant: Change SYS_UID_MAX and SYS_GID_MAX to 1001

# /etc/login.defs
SYS_UID_MAX              1001
SYS_GID_MAX              1001

To be on the safe side, the machine was rebooted. But that did not help: After a short time, the same errors occur again.

More complicated variant: Changing the UID from 1001 to 990

$ cat /etc/passwd
...
polkitd:x:997:997:User for polkitd:/:/usr/sbin/nologin
systemd-coredump:x:998:998:systemd Core Dumper:/:/usr/sbin/nologin
tomcat:x:999:999:Apache Tomcat:/:/sbin/nologin
oli:x:1000:1000:Oli Sennhauser,,,:/home/oli:/bin/bash
dba:x:1001:1001:DBA user:/home/dba:/bin/bash
...

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

To do this, all processes of this user must be stopped!

$ usermod --uid 990 dba
$ groupmod --gid 990 dba

$ find / -user 1001 -exec chown --no-dereference dba {} \;
$ find / -group 1001 -exec chgrp --no-dereference dba {} \;

This seems to have solved the problem!

Additional information

A source mentioned above also recommended setting the following parameters in systemd-logind:

# /etc/systemd/system/systemd-logind.service.d/override.conf
RemoveIPC=no
RuntimeDirectorySize=1%

However, this measure is no longer necessary as it works without this change.

This page was translated using deepl.com.