Qualcuno sta cancellando i miei segmenti di memoria condivisa!

Quando lavoriamo con PostgreSQL su myEnv, riceviamo regolarmente errori relativi al segmento di memoria condivisa. Esempio:

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

oppure vediamo messaggi simili nel log degli errori di PostgreSQL:

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

Essendo un amministratore MariaDB/MySQL, non ho molta familiarità con i problemi relativi alla memoria condivisa (MariaDB/MySQL non funziona con la memoria condivisa). Fortunatamente, una ricerca su Internet ci ha portato su una pista (fonte). Qui si legge:

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?

Utente di sistema Linux

Per prima cosa ho dovuto capire cosa fosse un utente di sistema in Linux. Ho trovato una risposta qui: 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.

Lo standard LSB dice: 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.

Sul mio sistema Ubuntu appare come segue:

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

Per l’utente PostgreSQL sarebbe corretto:

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

Ma poiché l’istanza PostgreSQL interessata funziona sotto il nostro myEnv, è diverso:

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

Ora abbiamo due possibilità:

1. Modifichiamo SYS_UID_MAX e SYS_GID_MAX su 1001 (variante semplice).
2. Oppure modifichiamo l’UID e il GID del nostro utente dba a meno di 1000.

Variante semplice: modifica di SYS_UID_MAX e SYS_GID_MAX a 1001

# /etc/login.defs
SYS_UID_MAX              1001
SYS_GID_MAX              1001

Per sicurezza, la macchina è stata riavviata. Tuttavia, ciò non è servito: dopo poco tempo si verificano nuovamente gli stessi errori.

Variante più complessa: modifica dell’UID da 1001 a 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)

A tal fine, tutti i processi di questo utente devono essere arrestati!

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

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

Il problema sembra essere risolto!

Informazioni aggiuntive

Una fonte citata in precedenza consigliava di impostare i seguenti parametri in systemd-logind:

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

Tuttavia, questa misura non è più necessaria, poiché il sistema funziona anche senza questa modifica.

Questa pagina è stata tradotta utilizzando deepl.com.