개발자보다 서버 관리자 관점에서 더 많은 관심을 보입니다. 현실 세계 예를 들어 실행중인 펄 실행 파일의 출처 확인
, 나는 보여줍니다 추신 AUX IN 라인이 있다고 가정 :usercom 1696 0.1 0.2 34104 4556 ? Ss 07:33 0:20 ./mail
없는이 펄 스크립트입니다 본질적으로 명백하다,하지만 나는 "이 일을하는 것입니다 확인할 수 있습니다 (다른 것들에 추가) 렌더링하는 "-p 1696 lsof를 :
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
perl 1693 usercom txt REG 0,49 17326 99846241 /home/virtfs/usercom/usr/local/bin/perl
그래서 이것은 (오픈 VZ에서) 사용자가 펄 인터프리터에서 실행되는 스크립트가 있음을 알려줍니다.
이 스크립트의 cwd를 보면 "mail"실행 파일이없는 디렉토리가 생성됩니다.
질문 (서버 관리자의 관점에서) 현재 실행중인 perl 코드의 "원점"을 결정하는 몇 가지 기술은 무엇입니까? $ 0은 매우 쉽게 조작되므로 실행중인 펄 스크립트의 "소스"를 절대적으로 결정할 수있는 방법이 없다는 것을 받아 들였습니다. 또한 코드를 perl로 파이프하거나 평가할 수도 있습니다. 그럼에도 불구하고 펄 스크립트의 근원을 추적하는 좋은 방법을 아는 사람이 있습니까?
감사합니다. 사용자가 $ 0을 "sh test.sh"에서 "bogusfile.sh"로 변경하면 어떻게됩니까? – GoldenNewby
여전히 'bogus.sh'의 PID를 볼 수 있으며 동일한 정보를 사용할 수 있습니다 (테스트 및 perl 스크립트로 확인). 해당 $ pid의 'cwd'에 여러 개의 스크립트가있는 경우 'bogus'또는 grep 스크립트를 grep하여 '$ 0'(Perl의 경우) 스크립트를 변경할 수 있습니다. 내가 뭔가를 놓치면 사과드립니다. – Woody2143
나는 좀 더 보았다. '/ proc/$ pid /'에서 'sched', 'stat'및 'status'파일에는 스크립트의 원래 이름이 들어 있습니다. 나는 '$ 0'을 변경 한 스크립트에 대해 이것을 테스트했다. – Woody2143