Solución 1:
sistema ignora completamente /etc/security/limits*. Si está utilizando un RPM que aplasta automáticamente su archivo de servicio systemd en la actualización, querrá presentar un PR para pedirles que marquen esos archivos como 'noreplace'
Debe actualizar el archivo .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
enfermedad señaló que también puede anular los valores instalados en el paquete (que se encuentran en el archivo anterior) agregándolos a /etc/systemd/system/<servicename>.d/override.conf
[Service]
LimitNOFILE=49152
Esto proporciona la ventaja adicional de configuraciones específicas del sistema que no corren peligro de sobrescribirse en la actualización del paquete.
Luego emita el comando:systemctl daemon-reload
Solución 2:
Archivos de configuración en /usr/lib/systemd/system/ debería no ser editado a mano y es perfectamente normal (si no se espera) que un rpm actualice los archivos que administra en este directorio en la actualización.
Como @sickill y @Cherif KAOUA señalaron en los comentarios [https://stackoverflow.com/questions/27849331/how-to-set-nginx-max-open-files/36423859#36423859] debe agregar una configuración personalizada que incluya límites en /etc/systemd/system/<servicename>.service.d/override.conf . por ejemplo:
[Service]
LimitNOFILE=65536
A continuación, vuelva a cargar la configuración del demonio systemctl:
systemctl daemon-reload
RHEL tiene una excelente sección sobre systemd en su Guía del administrador del sistema que, entre otras cosas, enumera dónde deben ubicarse los archivos de la unidad systemd y cómo anular los valores predeterminados.