☰

이것은 시뮬레이션이나 이론이 아니고 실제 생활이고 생각만큼 화려하지 않기 때문에 정전 후 고아에 대응하는 방법과 프로그램이 처리하지 못할 때 다시 시작하는 방법에 대해 다시 도움을 요청했습니다. 올바른 방법 PID 파일의 존재

tag-icon • tag-icon linux systemd process pidfile
이것은 시뮬레이션이나 이론이 아니고 실제 생활이고 생각만큼 화려하지 않기 때문에 정전 후 고아에 대응하는 방법과 프로그램이 처리하지 못할 때 다시 시작하는 방법에 대해 다시 도움을 요청했습니다. 올바른 방법 PID 파일의 존재

그런 상황에 부딪혔어요

  1. 정전
  2. 정전 중 UPS 배터리 방전
  3. 정전으로 인해 랙의 서버가 종료됨
  4. 전력 회복
  5. 서버가 시작되고 운영 체제가 시작되는 중입니다.
  6. systemd가 제 역할을 하고 있어요
  7. 그리고

지금일부 소프트웨어(시스템 서비스 시작 스크립트)는 깊은 블랙홀에 빠져 있습니다.ryles 시작은 pid 파일(var/run)의 프로세스에 있는 PID(번호)가 여전히 존재하는지 확인하는 대신 pid 파일이 존재하는지 여부에 따라 달라집니다. 시작을 거부하여 불필요한 계단식 연결이 발생할 수 있습니다...

이제 내 질문

  1. 나는 소프트웨어 디자이너가 아니기 때문에 디자이너가 자신의 창작물을 "올바르게 또는 그래야 하는 대로" 작업하도록 만들거나 강요하는 소프트웨어 관리자가 될 수도 없습니다.
  2. 특히 모든 업데이트 후에 모든 서비스가 예상대로 작동하는지 확인하기 위해 계속해서 최신 정보를 확인할 수 없습니다.

3) 이 상황을 전 세계적으로 어떻게 유지합니까?

a) its good idea o make a script and execute it on systemd service 
on each boot of server (linux kernel) to verify of pid file
processes existence ?  in case  of ps gone delete the pid file  

b) if so where such entry point for such service should be

c) how such script should handle the systemd services 
especially multiple .services file  location and the pid file named in those service files *with use of find or grep tools" .. 
as a blocking service ? it wold be a time cost solution ... 

d) or there is already better solution if so which one ? or some already made soft ?

maybe just hook after a init (process) ? and do just rm all *.pid ? by find -name *.pid ? exec rm ? it wold be 99% of job done :D

or do a systemd unit ExecStartPre= script for such each service to delete itself ? but it wold be time consuming to trace and edit service file and there is a "update" issue when sysyemd scirpt get changed by author ???

  1. 아니면 서비스 스크립트를 방해하지 않고 각 시스템 서비스에 대해 PreExecScipt를 일괄/전역적으로 실행할 수 있는 고유한 섹션이 있습니까?

첨부된:

마지막 질문... 제가 진짜 문제에 대한 해결책을 물을 때, 당신은(피해자로서) 제 때문에 개발자의 실수에 대해 저를 처벌하시겠습니까... 왜요?

나는 다른 오류나 지식 부족 또는 지식 부족에 대해 책임을 지지 않습니다.

PS2.

"매일 사용하고 설치하는 모든 소프트웨어의 성능을 볼 수는 없지만 이런 그룹이 있어서 비슷한 문제가 있어서 예방하고 싶습니다."

ps3. 알았어, 언제쯤이면 달리기폴더 나는 DEBIAN 및 기타 배포판에 대한 규칙을 알고 있습니다. 예를 들면 다음과 같습니다.

https://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2Fvar.2Frun_to_.2Frun_and_.2Fvar.2Flock_to_.2Frun.2Flock.3F

https://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2Fvar.2Frun_and_.2Fvar.2Flock

https://wiki.debian.org/ReleaseGoals/RunDirectory#Why_can.27t_.2Fvar.2Frun_and_.2Fvar.2Flock_stay_under_.2Fvar.3F

이것은 시뮬레이션이나 이론이 아니고 실제 생활이고 생각만큼 화려하지 않기 때문에 정전 후 고아에 대응하는 방법과 프로그램이 처리하지 못할 때 다시 시작하는 방법에 대해 다시 도움을 요청했습니다. 올바른 방법 PID 파일의 존재

소프트웨어 개발자 핸드북에서

Kea의 서버는 시작 시 PID 파일을 생성합니다. keactrl은 이러한 파일을 사용하여 특정 서버가 실행 중인지 확인합니다. 시작 명령을 실행할 때 하나 이상의 서버가 실행 중인 경우 출력은 다음과 유사합니다.

keactrl start
INFO/keactrl: kea-dhcp4 appears to be running, see: PID 10918, PID file: /usr/local/var/run/kea/kea.kea-dhcp4.pid.
INFO/keactrl: kea-dhcp6 appears to be running, see: PID 10924, PID file: /usr/local/var/run/kea/kea.kea-dhcp6.pid.
INFO/keactrl: kea-dhcp-ddns appears to be running, see: PID 10930, PID file: /usr/local/var/run/kea/kea.kea-dhcp-ddns.pid.
INFO/keactrl: kea-ctrl-agent appears to be running, see: PID 10931, PID file: /usr/local/var/run/kea/kea.kea-ctrl-agent.pid.
INFO/keactrl: kea-netconf appears to be running, see: PID 10123, PID file: /usr/local/var/run/kea/kea.kea-netconf.pid.

정상적인 종료 중에는 이러한 PID 파일이 삭제되지만 시스템 충돌 후 남은 파일로 남아 있을 수 있습니다. 가능성은 거의 없지만 시스템이 다시 시작되면 포함된 PID가 실제로 Kea와 관련 없는 프로세스를 참조할 수 있습니다. 이러한 상황으로 인해 keactrl은 실제로 서버가 실행되고 있지 않은데도 서버가 실행 중이라고 판단하게 됩니다. 이 경우 keactrl 출력에 나열된 PID 파일을 수동으로 삭제해야 합니다.

따라서 우리는 비휘발성 inode에서 pid로 끝납니다 -> /usr/local/var/run

최선을 다해 T. Best라고도 불리는 ceph3us

답변1

발견한 바와 같이 시스템이 시작될 때 여전히 존재하는 PID 파일은 시스템의 새로운 상태를 올바르게 나타내지 않습니다. 느린 PID 파일은 초기화 프로세스를 오해하고 손상시킬 수 있습니다. PID 파일 사용에 대한 기본 가정은 전원이 끊길 때 폐기되도록 휘발성 경로에 해당 파일을 쓰는 것입니다.

PID 파일의 규칙은 /run휘발성 파일 시스템을 사용하는 데 필요한 경로입니다. 일반적으로 이것은임시 파일 시스템휘발성 RAM에만 존재합니다. 역사적인 이유로 비휘발성 파일 시스템에서 실행이라는 이름의 심볼릭 링크 /var도 있습니다 . 대신 마운트된 파일 시스템 은 다음 과 같습니다./run/var/run -> /run/usr/local아니요변동성이 예상됩니다. 또한보십시오파일 시스템 계층 표준.

링크/실행

간단한 해결책은 /run서비스가 PID 파일을 작성하려는 위치에 연결하는 것입니다. 연결된 디렉터리는 표준 경로와 동일한 의미를 갖습니다.

귀하가 식별한 문제가 있는 PID 파일카이아서비스는 /usr/local/var/run이렇습니다.

# (first stop whatever is using /usr/local/var/run)
# rm -Rf /usr/local/var/run
# ln -s /run /usr/local/var/run

제 생각에는 이것이 해결 방법이며 올바른 해결책은 수정하는 것입니다.카이아서비스 스크립트는 정규화된 경로를 사용합니다. 하지만 이 링크를 사용하는 것은 안전한 방법이며 문제를 예방할 수 있습니다. 이 경로를 사용하는 다른 사람도 혜택을 누릴 수 있습니다.

그러나 /run루트가 소유하므로 /usr/local/var/run이 해결 방법은 사용된 서비스가 루트로 실행되는 경우에만 작동합니다. 그렇지 않은 경우 연결하는 것도 /tmp또 다른 해결 방법입니다.분명한다음과 같은.

비휘발성 PID 파일이 저장된 다른 위치가 있는 경우 설치의 다른 위치에 이 해결 방법을 적용해야 할 수도 있습니다.

재구성

또 다른 옵션은 올바른 경로를 사용하도록 해당 스크립트를 구성하는 것입니다. 일반적으로 초기화 스크립트는 다음으로 시작합니다.기본파일 예 /etc/default/kea: . 사용 가능한 옵션을 찾으려면 서비스 설명서나 스크립트를 참조해야 합니다.

분명한

PID 파일을 작성하기 위해 전용 계정을 사용하는 서비스의 경우(예:케아 사용자) 해당 계정의 cron 테이블 항목을 사용하여 시작 시 PID 파일을 삭제함으로써 PID 파일의 예상되는 변동성을 시뮬레이션할 수 있습니다. 예를 들어:

@reboot rm -f /usr/local/var/run/kea.pid

예제는 다음과 같이 편집됩니다 # crontab -e -u kea-user.

관련 정보