Изучая причину зависания / сбоя сервера, я обнаружил много сообщений selinux в / var / log / messages. Например:
setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file /tmp/sess_s5etafvc5ito5qi9icvpc17vi5. For complete SELinux messages. run sealert -l 9d054e4e-fc34-41a3-8fc5-4015026d2c6c
Не уверен, что это актуально, но группе из них предшествуют или следуют многие строки
audispd: queue is full - dropping event
В любом случае, выполнение предложенной команды sealert дает
SELinux is preventing /usr/sbin/httpd from getattr access on the file /tmp/sess_aa0iif62mu7nd4a4hb4g72slv3.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that httpd should be allowed getattr access on the sess_aa0iif62mu7nd4a4hb4g72slv3 file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
ls -l показывает, что он принадлежит root
-rw-------. 1 root root 0 Dec 2 05:03 sess_aa0iif62mu7nd4a4hb4g72slv3
Я плохо разбираюсь в каталоге или сеансах / tmp. Существуют файлы сеанса, принадлежащие httpd, так зачем httpd пытаться получить доступ к файлам сеанса, принадлежащим root? Почему вообще существуют файлы сеансов, принадлежащие root? Об этом нужно беспокоиться или исправить? Могут ли сотни или тысячи из них привести к блокировке сервера / панике ядра?
Кажется, что у вас есть движок приложения, такой как PHP, работающий от имени пользователя root. Подтвердите пользователя, владеющего процессом для каждого из ваших серверных демонов, с помощью ps или top.