Soluzione 1:
systemd ignora completamente /etc/security/limits*. Se stai utilizzando un RPM che elimina automaticamente il suo file di servizio systemd durante l'aggiornamento, ti consigliamo di presentare un PR per chiedere loro di contrassegnare quei file come "noreplace"
Devi aggiornare il file .service /usr/lib/systemd/system/<servicename>.service
[Unit]
Description=Some Daemon
After=syslog.target network.target
[Service]
Type=notify
LimitNOFILE=49152
ExecStart=/usr/sbin/somedaemon
[Install]
WantedBy=multi-user.target
malattia ha sottolineato che puoi anche sovrascrivere i valori installati dal pacchetto (trovati nel file sopra) aggiungendoli a /etc/systemd/system/<servicename>.d/override.conf
[Service]
LimitNOFILE=49152
Ciò fornisce il vantaggio aggiuntivo di impostazioni specifiche del sistema che non corrono il rischio di essere sovrascritte durante l'aggiornamento del pacchetto.
Quindi dai il comando:systemctl daemon-reload
Soluzione 2:
File di configurazione in /usr/lib/systemd/system/ dovrebbe non essere modificato a mano ed è perfettamente normale (se non previsto) che un rpm aggiorni i file che gestisce in questa directory durante l'aggiornamento.
Come hanno sottolineato @sickill e @Cherif KAOUA nei commenti [https://stackoverflow.com/questions/27849331/how-to-set-nginx-max-open-files/36423859#36423859] dovresti aggiungere una configurazione personalizzata che includa i limiti in /etc/systemd/system/<servicename>.service.d/override.conf . es:
[Service]
LimitNOFILE=65536
Quindi ricaricare la configurazione del demone systemctl:
systemctl daemon-reload
RHEL ha un'ottima sezione su systemd nella sua Guida per l'amministratore di sistema che, tra le altre cose, elenca dove dovrebbero essere posizionati i file di unità di systemd e come sovrascrivere i valori predefiniti.