grep은 "1000ms 이상 걸린 작업"을 뽑은 건데, 여기서 보이는 건 전부 정상 복구/종료 시간 이지 실패 원인은 아닙니다. 다만 한 가지 유의미한 게 보입니다: 7월 7일 복구가 18.7초(그중 체크포인트 14.9초) 걸렸습니다. 나머지도 2~6초대. 이건 매번 비정상 종료(전원차단/kill) 후 재시작하며 WiredTiger가 로그를 재생(recovery) 하고 있다는 신호입니다. ctx: SignalHandler 로 종료된 기록들도 보이는데, 이는 시그널(kill/service stop 등)로 내려간 것이고 그 자체는 정상입니다. 즉 데이터 손상은 아니고 (매번 recovery가 "successfully finished"), 단지 지저분한 종료가 반복되고 있을 뿐입니다. 그런데 지금 본질적인 질문으로 돌아가면 — 아까 processManagement.fork 가 config에 없다는 걸 확인했고, 그게 service mongod start 실패의 직접 원인이었습니다. 그 fork 블록을 추가하셨나요? 지금 로그 분석보다 그게 먼저입니다. 지금 상태를 한 번에 확정하죠: sh # 1) fork 블록이 config 에 들어갔는지 grep -A2 processManagement /usr/local/etc/mongodb.conf # 2) 지금 mongod 가 떠 있는지 (포그라운드로 띄운 게 남아있을 수도) sockstat -4 -l | grep 27017 ps aux | grep -E "[m]ongod" # 3) 서비스로 정식 시작 pkill -f 'mongod --dbpath' 2>/dev/null # 아까 수동 실행분 정리 service mongod start service mongod status 세 가지 경우로 갈립니다: (1)에 fork 블록이 있고 service mongod start 성공 → 끝. 이제 정상입니다. (반복되던 recovery는 아래 "지저분한 종료" 항목 참고) fork 블록을 아직 안 넣었으면 → 지금 넣으세요: sh printf '\nprocessManagement:\n fork: true\n pidFilePath: /var/db/mongodb/mongod.pid\n' >> /usr/local/etc/mongodb.conf service mongod start 넣었는데도 start 실패 → 그때 /var/db/mongodb/mongod.log 의 가장 최근 세션 마지막 줄을 주세요. 반복되는 recovery(지저분한 종료)도 짚고 갑니다. 매 재시작마다 2~18초씩 로그 재생을 하는 건, mongod가 깨끗이 안 내려가고 있다는 뜻입니다. 원인은 보통: service mongod stop 없이 전원 차단/리셋 fork가 없어서 rc가 프로세스를 제대로 관리 못 함 (→ fork 추가하면 service mongod stop 이 정상 동작해서 개선됨) 그래서 fork 추가는 start 실패 해결 + 깨끗한 종료 두 가지를 동시에 잡아줍니다. 앞으로는 끌 때 반드시: sh service mongod stop # kill 말고 이걸로 정리하면, 지금 로그의 recovery 시간들은 "손상"이 아니라 "지저분한 종료의 흔적"이고, 데이터는 매번 정상 복구되고 있습니다. 핵심 조치는 여전히 processManagement.fork 추가 → service mongod start 입니다. 위 1~3번 결과 주시면 확정해 드리겠습니다.