Postfix가 삭제되고 다시 작성된 후에 더 이상 / var / log / mail에 로그하지 않습니까?

실수로 /var/log/mail파일을 삭제했습니다 . 그때까지 나는 postfix 물건을 사용하여 그것을 모니터링 할 수있었습니다. 이제 /var/log/mail파일이 새 로그 메시지로 업데이트되지 않기 때문에 Postfix가 로그를로 보내지 않는 것 같습니다 .

mail.log 파일을 삭제하면 rsyslog (ubuntu)가 파일 핸들을 느슨하게합니다. 우분투에서 다시 작동하게하려면 다음을 제공하십시오.

sudo service rsyslog restart

이렇게하면 새 파일이 생성 될뿐만 아니라 로그 쓰기도 시작됩니다.

빈 파일을 만든 후에도

touch /var/log/mail

syslog를 다시 시작해야합니다

service syslog restart

그런 다음 로깅 이득입니다 :)

이것은 syslog의 버그이지만 파일이 프로그램에 의해 열려있는 동안 파일을 삭제할 때 발생하는 일반적인 문제를 보여줍니다. "rm"을 수행하면 디렉토리 항목이 제거되지만 기본 파일은 제거되지 않습니다. 운영 체제는 파일에 대한 참조 수를 유지하며 참조 수가 0이 될 때까지 기본 파일 데이터를 실제로 삭제하지 않습니다. 평균 파일의 경우 열지 않은 파일의 참조 카운트는 하나입니다 (디렉토리 항목). 파일이 열리면 카운트가 2로 증가합니다. 두 번째 프로그램이 같은 파일을 열면 카운트가 3으로 증가합니다. 디렉토리 항목이 이제 삭제되면 개수가 2로 감소합니다. 즉, 파일이 익명이며 (이름이 없음),

/ var / log / mail을 삭제해도 시스템 로거는 파일을 쓰기 위해 열려 있습니다. 새 / var / log / mail을 작성하면 시스템 로거가 현재 쓰고있는 파일과 다른 파일을 가리 킵니다. 모든 것을 일관되게 만드는 유일한 방법은 시스템 로거를 다시 시작하는 것입니다. 원래 시스템 로거가 종료되면 디렉토리 항목을 삭제 한 익명 메일 로그를 포함하여 이와 관련된 모든 파일이 닫힙니다. 시스템 로거를 다시 시작하면 로그 메시지를 작성해야 할 때 / var / log / mail을 다시 열고 이후에도 계속 열어 둡니다.

이것이 자주 발견되는 또 다른 방법은 실행중인 프로그램이 파일 데이터로 모든 디스크를 채울 때입니다. 사용자는 매우 큰 파일을 삭제하지만 파일이 여전히 존재하고 디스크 공간을 차지하기 때문에 디스크 공간이 비워지지 않지만 디렉토리 항목이 제거되었습니다. 사용자가 프로그램을 종료했거나 종료했기 때문에 프로그램이 종료되면 파일의 참조 횟수가 0이되어 디스크 공간이 복구됩니다.

로거가이를 방지하기 위해 먼저 로그 메시지를 작성하고 로그 파일 디렉토리 항목이 존재하는지 확인하고 존재하지 않는 경우 원래 로그 파일을 닫고 새 파일을 연 다음 다시 작성하십시오. 메시지-메시지가 손실되지 않도록합니다. 그러나 모든 작업을 수행하려면 시스템 로거가 가져야 할 것보다 훨씬 더 복잡한 작업이 필요합니다. 각 메시지마다 추가 디렉토리 확인으로 인해 기록하는 데 시간이 조금 더 걸립니다. 파일이있을 때마다 성공합니다. 삭제되지 않았습니다.

위의 모든 내용을보다 명확하게 이해하려면 다음 명령이 도움이됩니다. 디렉토리 항목 제거 및 참조 감소를 수행하는 시스템 호출을 설명하기 때문입니다. "man 3 unlink"

CentOS 7에서는 문제가되지 않습니다. 누군가 저널리스트를 통과하기 위해 접미사 메일 로그를 작성하는 것이 좋은 아이디어라고 생각했습니다. 접미사 로그를 보려면 다음을 수행하십시오.

journalctl -u postfix

(전체 로그를 보려면)

journalctl -u postfix -f

(로그를 꼬리로)

postfix를 위해 main.cf에 필요할 수도 있습니다.

syslog_name = postfix

FWIW 새에 접미사 로그의 버전 /var/log/mail.log과 나는 또한 실행했다 sudo chmod a+w /var/log/mail*및 service postfix restart을 삭제 한 후 다시 내 후위 로그를 얻을 수