저는 신뢰성이 높은 Linux 시스템(커널 5.0.19)을 모니터링하고 수정 조치를 취하도록 설계된 일부 셸 스크립트를 작성 중입니다. 이러한 작업 중 하나는 경우에 따라 시스템을 재부팅하는 것입니다.
재시작 코드를 작성하는 방식으로 호출을 백그라운드에 두어 /sbin/reboot now &바로 코드에서 다른 작업을 시작할 수 있습니다. 이 맥락이 제가 완전히 이해하지 못하는 어떤 의미를 담고 있지는 않을까 걱정됩니다. 인터넷 검색은 이에 대한 실제 정보를 제공하지 않았습니다. 백그라운드 재시작 또는 종료 명령이 Linux에서 좋은 결정인지 나쁜 결정인지에 대한 지식이나 의견을 제공할 수 있는 사람이 있습니까?
추가 세부 사항 위에서 지정한 지침에 따라 내가 작성한 이 다시 시작 프로세스는 다음을 수행해야 합니다.
- 정상적으로 안전하게 다시 시작해 보세요.
- 재부팅이 중단되면 시스템을 하드 리셋하세요.
- 하드 리셋이 실행될 때 메모리에 있는 최대한 많은 데이터가 디스크에 기록되는지 확인하십시오.
시스템의 하드 리셋은 시스템에 납땜된 하드웨어 감시 회로로 인해 트리거되며, 이로 인해 모든(~99.9%) 재부팅이 하드 리셋으로 작동하게 됩니다.+소프트웨어 워치독 데몬프로세스. 감시 프로세스를 종료하면 하드 리셋이 발생하기 전 60초 카운트다운이 트리거됩니다.
내가 코드를 작성하는 방식은 다음과 같습니다.
- 감시 프로세스를 종료하고 하드 리셋 카운트다운을 시작합니다.
- 정상적으로 다시 시작하고 프로세스를 백그라운드에 넣어보세요.
/sbin/reboot now & reboot명령이 중단되었다고 가정하고 지속적으로 동기화를 시작합니다.
내 재시작 기능과 관련된 스니펫은 다음과 같습니다.
# Kill watchdog daemon process(es), this starts 60s countdown to hard reset
pkill -9 watchdog
if (( $? == 0 )); then
logThis INFO "Watchdog processes killed successfully, creatinged \"$watchdogTriggeredFile\""
touch $watchdogTriggeredFile
fi
# Attempt a normal reboot before the watchdog forces ember to reboot
/sbin/reboot now &
# In testing, anytime the watchdog forces a reboot we lose ~15-25
# seconds of logs. This is due to log writes being stored in memory.
# The watchdog process does not call sync before it kills power to the
# system, so anything stored in memory is lost, therefore:
# Constantly write memory to disk until watchdog triggers reboot (60s)
for (( n=0; n<=600; n+=2)); do
# Watchdog forces reboot after 60s, we sleep every .2, 60 / .2 = 300 iterations
# Can't do floating point arithmetic in bash so we use 600 / 2 = 300 instead
# 300 iterations is more than 60s due to context switching and execution time
sync
sleep 0.2
done
reboot now그렇다면 계속 동기화를 시도할 수 있도록 위 코드의 백그라운드 호출에 큰 문제가 있을 수 있습니까 ?