아주 따끈따끈한 이슈를 발견해서 포스팅한다.
직접 테스트를 하는데... 저장이 안된다...
"뭐지?" 하면서 살펴보기 시작한다.
rdsosreport 를 고객이 제공해서 살펴본다.
kdump.conf 에서 default shell 로 설정하면, 덤프실패시 kdump emergency shell 이 실행되는데
여기서 /boot/initramfs/rdsosreport.txt 파일이 일련의 로그를 담고 있고,
이를 복사하면 분석에 도움이 된다.
[ 2.356925] kernel: SGI XFS with ACLs, security attributes, realtime, no debug enabled
[ 2.370265] kernel: XFS (dm-0): Mounting V4 Filesystem
[ 2.389509] systemd[1]: Started dracut pre-pivot and cleanup hook.
[ 2.389706] systemd[1]: Starting Kdump Vmcore Save Service...
[ 2.430291] systemd[1]: kdump-capture.service: main process exited, code=exited, status=1/FAILURE <<<
[ 2.430514] systemd[1]: Failed to start Kdump Vmcore Save Service. <<<
[ 2.430766] systemd[1]: Unit kdump-capture.service entered failed state.
[ 2.430971] systemd[1]: Triggering OnFailure= dependencies of kdump-capture.service.
[ 2.431155] systemd[1]: kdump-capture.service failed. <<<
[ 2.431325] systemd[1]: Stopped File System Check on /dev/mapper/vg_sys-lv_crash. <<<<
위에서와 같이 kdump-capture.service 가 실패됨을 확인할 수 있다.
실재 kdump emergency shell 에서 해당 XFS 타겟이 정상적으로 마운트 되어 있음을
확인했는데도 실패한 것으로 나온다.
그냥 kdump shell 에서 systemctl restart kdump-capture 를 수행하면
정상적으로 덤프가 저장된다..
다시 실패했을때의 콘솔로그를 확인해 보자.
조기 보면 kdump save service 가 실패했음을 알 수 있다.
곰곰히 잘 살펴보면, dump save 를 위한 target 을 못찾는 것으로 보인다.
또한 filesystem check 관련 작업이 저 작업 후 완료됨을 볼 수 있다.
직감적으로 Sequence 문제임을 파악한다.
저 서비스가 어디에 놓여져 있는지 확인이 필요하다.
# rpm -ql kexec-tools 를 수행하면
/usr/lib/dracut/modules.d/99kdumpbase/kdump-capture.service 라는 파일목록이 나온다.
열어보면 아래와 같이 되어 있다.
[Unit]
Description=Kdump Vmcore Save Service
After=initrd.target initrd-parse-etc.service sysroot.mount
After=dracut-initqueue.service dracut-pre-mount.service dracut-mount.service dracut-pre-pivot.service
Before=initrd-cleanup.service
ConditionPathExists=/etc/initrd-release
OnFailure=emergency.target
OnFailureJobMode=isolate
[Service]
Environment=DRACUT_SYSTEMD=1
Environment=NEWROOT=/sysroot
Type=oneshot
ExecStart=/bin/kdump.sh
StandardInput=null
StandardOutput=syslog
StandardError=syslog+console
KillMode=process
RemainAfterExit=yes
요걸 이용하면 어떻게든 수행할 수 있을거라는 직감이 든다.
딜레이를 주자....
systemd 에 딜레이를 주는 옵션들은 상당히 많다.
귀찮아서 유럽애 한명(Sbinner) 에게 Slack 으로 이런 이슈 본적 있냐고 물어보니까,
자기 얼마전 본거같다고... 레드햇 버그질라에서 본거같다고 한다..
https://bugzilla.redhat.com/show_bug.cgi?id=1809179
오.... 땡큐 하고 찾아보니, 역시 레드햇애들도 해결은 아직 안됬고,
delay time 을 주면 해결이 될거로 보인다고 의견만 제시한 상태다..
그리고선 웬 systemd configuration 관련 stackover flow 사이트를 던저준다.
https://stackoverflow.com/questions/39284563/how-to-set-up-a-systemd-service-to-retry-5-times-on-a-cycle-of-30-seconds
아래와 같은 옵션을 제안한다.
[Unit]
StartLimitInterval=200
StartLimitBurst=5
[Service]
Restart=always
RestartSec=30
이는 30초마다 5번씩 다시 재시작하라는 것으로 보인다.
적용해보았으나 안된다. 기다려보면 됐을지도 모르겠는데
사이트의 내용을 보면 Type 이 forking 일 때 만 된다는 식으로 나온다.
하지만 kdump-capture service 는 oneshot 타입이다.
forking 으로 해도 안되는거 같은데 귀찮아서 그냥 테스트 안하기로 했고,
Soren 역시 이미 충분히 테스트 한거같으니 더 하지 말라고 한다...
역시 나의 방법을 사용하기로 했다.
이미, Sbinner 에게 해당 내용을 듣기 전에 나의 워크어라운드로 아래와 같은 방법을
고객에게 제안한 상태였다
ExecStartPre=/bin/sleep 5 <<< kdump.sh 수행 전에 5 초 대기한다.
ExecStart=/bin/kdump.sh
해당 파일을 수정하고 /boot/initramfs-***kdump.img 를 지우고
kdump 를 재시작 해 준다.
# rm -rf /boot/initramfs-`(uname -r)`kdump.img
# systemctl restart kdump
테스트를 해본다.
# echo c > /proc/sysrq-trigger
아주 잘 저장됨을 볼 수 있다.
혹시라도 OL7 에서 별도의 XFS 에 덤프를 저장해야 하는 경우, 해당 워크어라운드를 적용하도록 하자.
당연히 기존 루트 파일시스템에 저장하는 경우는 fsck 가 앞서 수행되므로 상관없이 잘 된다.
대부분 5~10초면 무난하지 않을까 싶다.