로그가 한 달 동안 출력되지 않으면

개시하다
'본격 공연 환경에서 했던 사람.'16일째 보도다.
이것은 이전에 내가 관리했던 시스템에서 발생한 일이다.
무슨 일이 생겼어요?
그 시스템은 매달 한 번씩 방문 로그의 합계 결과를 모으는 정기적인 작업을 한다.
서버에서 하는 일은 로그를 얻는 것, 절차서를 얻는 것밖에 없기 때문에 매달 다른 멤버들에게 맡긴다.
장기간 출장 갔다가 오랜만에 자기 회사로 돌아와 숨 좀 돌리면서 밀린 일을 처리하다 보면
담당자 A: "땡땡이 시스템에 대해서는..."
견적서를 부탁하는 건가요?아니면 다음 계획 제안의 시스템 구성을 말할까요?출장 특산물을 한입 크게 먹으면서 듣는다.
담당 A: "00 시스템의 A 서버의 로그가 1개월 동안 출력되지 않았습니다."
어?

문제를 정리하다
다음은 청취의 결과.

한 달 동안 출력 로그가 없는 서버는 1대

마침 한 달 전에 지난달 로그 수령 작업을 했다

지난달 작업 중 원 로그를 잘못 삭제했습니다(!)

그래서 분명히 숙제 실수였어요.
복구 작업의 결과가 안전하게 로그에 출력될 수 있음을 확인하기 위해 부랴부랴 고객에게 보고를 했습니다.
그나저나 타겟 서버syslog에도 전송이 없고 OS도 RHEL5인지 6인지journal에 로그가 없어서 로그를 복구할 수 없습니다.
로그가 출력되지 않은 이유
결론적으로 백업에서 로그로 되돌아온 후 rsyslog 서비스가 다시 시작되지 않았기 때문이다.
각종 서비스, 프로그램에서 파일 열기, 쓰기 등 파일 작업을 할 때 파일 설명자를 통해 작업을 하지만 1개월 전 작업에서 원본 로그가 삭제되어 파일 설명자 관리가 배제되었다같은 이름의 파일이 같은 곳에 놓여 있어도 쓰여지지 않은 것이 원인이다.
같은 파일 이름을 반환한 파일도 왜 로그에 쓰지 않았을까.
명령줄 등을 사용하여 파일 조작을 할 때 파일 이름을 지정하여 조작하고 내부 핵에서는 inode를 보고 조작한다.inode 번호는 stat 명령 또는 ls -i 명령을 통해 확인할 수 있습니다.
stat 명령을 통해inode 번호 확인

# stat /var/log/messages
  File: `/var/log/messages'
  Size: 107495          Blocks: 216        IO Block: 4096   通常ファイル
Device: 805h/2053d      Inode: 9863630     Links: 1
Access: (0600/-rw-------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-12-03 07:48:52.668174258 +0900
Modify: 2021-12-03 07:48:07.242268153 +0900
Change: 2021-12-03 07:48:07.242268153 +0900
 Birth: -

inode번호는 mv에서 파일 이름을 변경했지만 cp에서 복사하면 inode번호가 바뀌기 때문에 외관상으로는 같은 파일 이름inode번호라도 다르기 때문에 완전히 다른 파일이다.
화면음악의inode 번호

# ls -i /var/log/messages
8481074 /var/log/messages
# mv /var/log/messages /var/log/messages.test
# ls -i /var/log/messages.test
8481074 /var/log/messages.test

cp 후의inode 번호

# ls -i /var/log/messages
8481074 /var/log/messages
# cp -p /var/log/messages /var/log/messages.test
# ls -i /var/log/messages.test
8481171 /var/log/messages.test

/proc/[プロセス番号]/fd 각 과정에 사용된 파일 설명자를 볼 수 있지만 원본 로그를 삭제하면 같은 파일 이름의 백업 파일deleted을 복원해도 /var/log/messages이 삭제된 상태임을 알 수 있다.
※ 다음은 센토스 7 재현의 예
파일을 반환한rsyslogd의 파일 설명자

# ls -l /proc/[プロセス番号]/fd
合計 0
lr-x------ 1 root root 64 12月  6 07:34 0 -> /dev/null
l-wx------ 1 root root 64 12月  6 07:34 1 -> /dev/null
l-wx------ 1 root root 64 12月  6 07:34 2 -> /dev/null
lr-x------ 1 root root 64 12月  6 07:34 3 -> anon_inode:inotify
lrwx------ 1 root root 64 12月  6 07:34 4 -> socket:[35399]
lr-x------ 1 root root 64 12月  6 07:34 5 -> /run/log/journal/7408d4861a614db99426cca5c8e364fb/system.journal
l-wx------ 1 root root 64 12月  6 07:34 6 -> /var/log/secure
l-wx------ 1 root root 64 12月  6 07:34 7 -> /var/log/messages (deleted)
l-wx------ 1 root root 64 12月  6 07:34 8 -> /var/log/cron
l-wx------ 1 root root 64 12月  6 07:34 9 -> /var/log/maillog

백업 파일에서 같은 파일 이름을 복원하더라도 rsyslog 삭제된 원본 파일과 관련이 있기 때문에 로그 파일의 링크를 다시 읽고 변경해야 합니다.
참극은 어떻게 발생했는가
사고 사례가 있는 교과서라면 먼저 소개한 것처럼 발생해야 할 문제다.

로그만 가져오는 데 사용되는 업무 의식 감소

비즈니스 환경에서 혼자 작업

절차설명서가 유지되지 않아 일부 사람의 판단이 필요하다

예상치 못한 문제는 개인의 판단에 따라 진행한다

더 이상 참극이 일어나지 않도록 왜
모든 관계자가 모여 사고가 왜 발생했는지, 무엇을 해야 방지할 수 있는지를 논의하고 향후 대책을 결정했다.
사람으로서의 대책은 당연한 것이지만, 다음 내용을 관철하기 위해 다시 한번 주지하겠다.

변경, 추가, 삭제 등 작업 시 1인 작업 금지

단계설명서를 수정하여 누구나 단계서에 따라 작업을 할 수 있도록 한다

사고 발생 시 즉시 보고

체계적인 대책으로 다음과 같은 내용을 논의하고 실시한다.

정기 작업의 자동화

가급적 변경, 추가, 삭제 등의 조작을 하지 않는 절차 토론

서버에 로그인하지 않아도 되는 시스템 설계에 대한 최초 논의

그러나 자동화도 때때로 돌이킬 수 없는 오류가 발생하여 2차 재해가 발생할 수 있으니 이 점을 주의하여 시험을 잘 실시해 주십시오.
끝말
사람은 아무리 업무에 주의를 기울여도 문제가 발생할 때 발생하지만 여러 번의 검사를 통해 서로 다른 관점으로 검사를 하면 줄일 수 있다고 생각합니다.
원래 체계화하면 실수 방지도 중요하지만, 구성원별 업무 의식에 대해서도 정기적으로 수정할 필요가 있다는 생각이 든다.