业精于勤,荒于嬉;行成于思,毁于随。
스크립트에 "잠금 파일을 삭제하고 새 잠금 파일을 생성합니다"라는 문구를 추가하여 위의 문제를 해결했습니다. 잠금 파일이 새로 생성될 때마다 crontab이 트리거되는 것을 발견했습니다.
그림에서 볼 수 있듯이 현재 시간이 499로 감지되면 nginxchen.sh라는 스크립트가 실행됩니다. 이 스크립트의 실행 시간은 약 8분입니다.
솔직히 구체적인 이유는 잘 모르겠습니다. 한 문장을 빌리자면, 진실을 검증하는 유일한 기준은 실천이기 때문에 원본 포스터의 시나리오를 그대로 흉내냈습니다.
1. 2분 이상 소요되는 스크립트를 작성하고 실행해 보세요
2. crontab에 넣으세요*/1 * * * * Flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2> &1 '
3. crontab 실행 내용 보기
원본 포스터에서 언급한 바와 같이 문제가 없음을 알 수 있다
다음 제안 사항은 다음과 같습니다.1. 짧은 스크립트를 작성하고 서버에서 테스트해 보세요. 작동하지 않으면 서버를 변경하여 상황이 동일한지 확인하세요.2. /mnt/499.log 로그. 비정상적인 출력 없음3. 프로세스가 실행 중이거나 중단되어 crontab이 잠금을 얻을 수 없는지 확인하세요.
그게 다입니다. 포스터가 스스로 이유를 찾았다면 게시하는 것을 잊지 마세요
스크립트에 "잠금 파일을 삭제하고 새 잠금 파일을 생성합니다"라는 문구를 추가하여 위의 문제를 해결했습니다. 잠금 파일이 새로 생성될 때마다 crontab이 트리거되는 것을 발견했습니다.
그림에서 볼 수 있듯이 현재 시간이 499로 감지되면 nginxchen.sh라는 스크립트가 실행됩니다. 이 스크립트의 실행 시간은 약 8분입니다.
솔직히 구체적인 이유는 잘 모르겠습니다. 한 문장을 빌리자면, 진실을 검증하는 유일한 기준은 실천이기 때문에 원본 포스터의 시나리오를 그대로 흉내냈습니다.
1. 2분 이상 소요되는 스크립트를 작성하고 실행해 보세요
2. crontab에 넣으세요
*/1 * * * * Flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2> &1 '
3. crontab 실행 내용 보기
원본 포스터에서 언급한 바와 같이 문제가 없음을 알 수 있다
다음 제안 사항은 다음과 같습니다.
1. 짧은 스크립트를 작성하고 서버에서 테스트해 보세요. 작동하지 않으면 서버를 변경하여 상황이 동일한지 확인하세요.
2. /mnt/499.log 로그. 비정상적인 출력 없음
3. 프로세스가 실행 중이거나 중단되어 crontab이 잠금을 얻을 수 없는지 확인하세요.
그게 다입니다. 포스터가 스스로 이유를 찾았다면 게시하는 것을 잊지 마세요