☰

init.d로 시작하면 PID가 다릅니다.

tag-icon • tag-icon sysvinit
init.d로 시작하면 PID가 다릅니다.

저는 현재 Debian 10 머신에서 소규모 서버로 실행하고 있습니다. aria2c를 설치해서 다운로드 서비스로 사용하고 있습니다. 지금까지는 모든 것이 괜찮을 것입니다. 내 질문은 다음과 같습니다

  • init.d 스크립트를 사용하여 aria2c를 데몬으로 시작합니다.
  • pid 파일이 작성됩니다.
  • 프로세스를 확인해 보니 aria2c의 PID가 파일의 PID와 다릅니다.

누군가 이유를 설명할 수 있나요? (참고 - 이것은 기능상의 문제가 아닙니다. 이유를 알고 싶습니다. 아니면 제가 뭔가 잘못하고 있는 것일 수도 있습니다...)

$ cat /var/run/aria2c.pid
561
$ sudo /etc/init.d/aria2 status
...
CGroup: /system.slice/aria2.service
       └─565 /usr/bin/aria2c --daemon=true --enable-rpc --conf-path=/etc/aria2.conf
$ pgrep aria2
565
$ ps ax | grep aria*
  565 ?        Ss     0:36 /usr/bin/aria2c --daemon=true --enable-rpc --conf-path=/etc/aria2.conf
$ cat /proc/56
56/  565/

이것이 나에게 의미하는 바는 프로세스 561이 더 이상 존재하지 않는다는 것입니다. 그런데 왜 내 pid 파일에 이 PID가 있는 걸까요?

답변1

나는 당신이 언급한 다운로더 데몬에 대한 경험을 부인하지만...

  1. RC 스크립트를 직접 작성하셨나요?
  2. aria2c달릴 때 제대로 멈추나요 /etc/init.d/aria2 stop?(즉, 느린 프로세스가 남아 있지 않습니까?)

(1)이 "예"이고 (2)가 "아니요"인 경우 다음과 같은 이유일 수 있습니다.aria2c진짜 일을 할 수 있는 아이를 낳아라, RC 스크립트에서 이를 제대로 억제하지 않았습니다.

많은 프로그램에는악마호출한 프로그램은 서브루틴에 대한 패턴을 생성하고악마:

  1. 이 프로그램은 하위 프로세스를 분기합니다.
  2. 하위 프로세스는 작업 디렉터리를 /.
  3. 하위 프로세스는 자체 표준 입력/출력/오류를 차단합니다.
  4. 하위 프로세스는 현재 세션에서 분리됩니다.
  5. 귀하가 호출한 상위 프로세스가 종료됩니다.
  6. 하위 프로세스는 실제 작업을 수행하기 위해 백그라운드에서 유지됩니다.

PID 파일에 캡처한 프로세스 ID는 아마도 종료된 상위 프로세스일 것입니다.

데몬( )을 중지하면 PID 파일의 프로세스 ID도 사용됩니다 /etc/init.d/aria2 stop. 잘못된 경우(예: 실제 데몬 대신 종료된 상위 프로세스 참조) 결과적으로 데몬이 중지되지 않으며 수동으로 종료해야 합니다.

aria2c솔루션을 실행할 필요가 없습니다.--daemon범위, 자체 데몬화를 방지하기 위해(올바른 프로세스 ID를 PID 파일에 저장할 수 있도록) 다음을 수행해야 합니다.악마RC 스크립트에 직접 참여해 보세요.

PS 이미 aria2cDebian을 통해 RC 스크립트를 실행하고 있는 경우start-stop-daemon도우미님, 그러면 대부분의 작업이 완료되었습니다.하지만 당신은 또한 제안 --background하고 --chdir /선택 해야start-stop-daemon.

관련 정보