배경: CentOS 6 LAMP 서버가 있습니다. 최근에 서버가 며칠마다 응답하지 않기 시작했습니다. 처음에 mysqld는 nagios 경고를 발생시켰고 서버에 SSH를 연결할 수도 없었으므로 하드 리셋이 필요했습니다. Mysqltuner가 버퍼 풀을 늘리도록 안내했는데 도움이 된 것 같습니다. 이제 증상은 apache http 다운 경고를 발생시키는 nagios로 변경되었습니다. 이번에는 SSH로 서버에 연결할 수 있었지만 Apache가 다시 시작되지 않아 다시 시작해야 했습니다.
/var/log/messages 및 /var/log/audit/audit.log를 검토한 후 수백 개의 AVC 오류를 발견했습니다. audit.log는 하루에 몇 MB인 반면 다른 서버의 크기는 kb에 불과합니다. 이것이 근본적인 문제에 대한 단서가 될 수 있습니까?
일반적인 /var/log/messages 항목은 다음과 같습니다.
Mar 31 16:50:39 web1 setroubleshoot: SELinux is preventing /bin/ps from getattr access on the directory /proc/<pid>. For complete SELinux messages. run sealert -l be51d126-d70e-491f-9ec8-f897677d9989
sealert 실행 결과는 다음과 같습니다.
SELinux is preventing /bin/ps from getattr access on the directory /proc/<pid>.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that ps should be allowed getattr access on the <pid> directory 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 ps /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
이것은 audit.log의 일반적인 항목입니다.
type=SYSCALL msg=audit(1427837702.229:721164): arch=c000003e syscall=4 success=no exit=-13 a0=8164d0 a1=3eaee11cc0 a2=
3eaee11cc0 a3=8164d6 items=0 ppid=2792 pid=2800 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1427837702.219:721127): avc: denied { getattr } for pid=2800 comm="ps" path="/proc/875" dev=proc
ino=9349054 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir
고쳐 쓰다 그런데 몇 달 뒤에 또 그런 일이 일어났어요. 내 LAMP 서버가 때때로 정지되는 이유를 파악하지 못했지만(MySQL이 Nagios 경고를 발생시키는 첫 번째 서비스이기 때문에 의심됩니다) SE Linux 경고(원래 질문에서)가 발생하는 이유를 알고 있습니다. 호스팅 사이트는 Magento 온라인 상점이고, 5분마다 실행되는 cron.php 스크립트로 인해 매번 SE Linux 오류가 발생합니다.
그래서 제가 업데이트한 질문은 다음과 같습니다. 내 메시지와 감사 로그에 있는 많은 항목 외에 걱정할 것이 있습니까?
답변1
마침내 범위를 좁히고 문제를 해결할 수 있었습니다. 이는 두 가지 문제가 결합된 것입니다.
서버의 Magento 사이트는 vhosts 파일에서 비활성화되어 있습니다. 그러나 Magento cron 작업은 계속 실행 중이며 실패하고 모든 AVC 오류가 발생합니다. 고아 크론 작업을 제거하면 AVC 오류를 방지할 수 있습니다.
그러나 Manuel Faux가 댓글에서 지적했듯이 SELinux 버그는 서버의 무작위 충돌과 관련이 없습니다. 그러나 AVC 항목이 더 이상 내 로그 파일을 복잡하게 만들지 않기 때문에 서버가 정지되기 전에 mysql 로그에서 다음을 찾을 수 있었습니다.
InnoDB: 경고: 긴 세마포 대기: -- 스레드 140485795231488이 btr0sea.c 라인 1706에서 241.00초 동안 대기했습니다. 세마포: btr0sea.c 라인 178 파일에 생성된 0x5583b18의 RW 래치에 대한 X 잠금이 생성되었습니다.
세마포어 대기에 대한 로그를 보고 이것에 대해 생각하게 되었습니다.관련 질문. 따라서 최종 해결책 innodb_adaptive_hash_index = 0
은 mysql 구성에서 설정하는 것입니다.
추가 단계로 모든 데이터베이스를 최적화하기 위해 매주 mysqlcheck도 만들었습니다. mysql이나 SELinux의 자발적인 충돌이나 더 이상 이상한 오류 로그 없이 몇 주가 지났습니다.