Quelqu'un supprime mes segments de mémoire partagée !

Lorsque nous travaillons avec PostgreSQL sous notre myEnv, nous obtenons régulièrement des erreurs de segment de mémoire partagée. Exemple:

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

ou nous voyons des messages similaires dans le journal d’erreurs PostgreSQL:

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

Comme je suis administrateur MariaDB/MySQL, je ne m’y connais pas très bien en matière de problèmes de mémoire partagée (MariaDB/MySQL ne fonctionne pas avec la mémoire partagée). Heureusement, une recherche sur Internet nous a mis sur une piste (source). On y trouve la mention suivante:

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?

Utilisateur du système Linux

J’ai d’abord dû découvrir ce qu’était un utilisateur du système sous Linux. J’ai trouvé une réponse ici: 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.

La norme LSB indique à ce sujet: 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.

Sur mon système Ubuntu, cela se présente comme suit:

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

Pour l’utilisateur PostgreSQL, cela serait également correct:

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

Mais comme l’instance PostgreSQL concernée fonctionne sous notre myEnv, c’est différent:

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

Nous avons donc maintenant deux possibilités:

1. Nous modifions SYS_UID_MAX et SYS_GID_MAX à 1001 (variante simple).
2. Ou nous modifions l’UID et le GID de notre utilisateur dba à moins de 1000.

Variante simple: modification de SYS_UID_MAX et SYS_GID_MAX à 1001

# /etc/login.defs
SYS_UID_MAX              1001
SYS_GID_MAX              1001

Par mesure de sécurité, la machine a été redémarrée. Mais cela n’a pas aidé: après peu de temps, les mêmes erreurs réapparaissent.

Variante plus compliquée: Modification de l’UID de 1001 à 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)

Pour cela, tous les processus de cet utilisateur doivent être arrêtés!

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

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

Le problème semble ainsi résolu!

Informations supplémentaires

Une source mentionnée plus haut recommandait encore de définir les paramètres suivants dans systemd-logind:

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

Cette mesure n’est toutefois plus nécessaire, car cela fonctionne également sans cette modification.

Cette page a été traduite à l’aide de deepl.com.