Jemand löscht meine Shared Memory Segmente!

Wenn wir mit PostgreSQL unter unserem myEnv arbeiten, kriegen wir regelmässig Shared Memory Segment Fehler. Beispiel:

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

oder wir sehen ähnliche Meldungen im PostgreSQL Error Log:

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

Weil ich ein MariaDB/MySQL Admin bin, kenne ich mich nicht so gut mit Shared Memory Problemen aus (MariaDB/MySQL arbeitet nicht mit Shared Memory). Zum Glück hat uns eine Suche im Internet auf eine Fährte geführt (Quelle). Dort wird vermerkt:

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

Zuerst musste ich mal herausfinden was ein System User unter Linux überhaupt ist. Eine Antwort habe ich hier gefunden: 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.

Der LSB Standard meint dazu: 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.

Auf meinem Ubuntu System sieht das wie folgt aus:

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

Für den PostgreSQL User würde das ja auch stimmen:

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

Da aber die betroffene PostgreSQL Instanz unter unserm myEnv läuft, ist das was anderes:

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

Jetzt haben wir also zwei Möglickeiten:

1. Wir ändern SYS_UID_MAX und SYS_GID_MAX auf 1001 (einfache Variante).
2. Oder wir ändern die UID und die GID unseres Users dba auf unter 1000.

Einfache Variante: Ändern von SYS_UID_MAX und SYS_GID_MAX auf 1001

# /etc/login.defs
SYS_UID_MAX              1001
SYS_GID_MAX              1001

Zur Sicherheit wurde die Maschine neu gebootet. Das ha aber nicht geholfen: Nach kurzer Zeit treten wieder die selber Fehler auf.

Kompliziertere Variante: Ändern der UID von 1001 auf 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)

Dazu müssen alle Prozesse dieses Users gestoppt sein!

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

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

Damit scheint das Problem gelöst zu sein!

Zusatzinformationen

Eine weiter oben erwähnte Quelle hat noch empfohlen, beim systemd-logind folgende Parameter zu setzen:

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

Diese Massnahme ist jetzt aber nicht mehr notwendig, das es auch ohne diese Änderung funktioniert.