일반적으로 환경 설정이 없으므로 cron에서 스크립트를 실행하는 방법에 몇 가지 문제가 있습니다. cron과 동일한 방식으로 bash (?)를 호출하는 방법이 있으므로 스크립트를 설치하기 전에 테스트 할 수 있습니까?
답변
이것을 crontab에 추가하십시오 (일시적으로).
* * * * * env > ~/cronenv
실행 후 다음을 수행하십시오.
env - `cat ~/cronenv` /bin/sh
이것은 cron이 / bin / sh를 실행한다고 가정합니다. 이는 사용자의 기본 쉘에 관계없이 기본값입니다.
답변
Cron은 기본적으로이 환경 만 제공합니다.
HOME
사용자의 홈 디렉토리LOGNAME
사용자의 로그인PATH=/usr/bin:/usr/sbin
SHELL=/usr/bin/sh
더 필요한 경우 crontab의 스케줄링 테이블 전에 환경을 정의하는 스크립트를 소싱 할 수 있습니다.
답변
몇 가지 접근 방식 :
-
cron env를 내보내고 가져옵니다.
더하다
* * * * * env > ~/cronenv
crontab에 한 번 실행 한 다음 다시 끈 다음 실행하십시오.
env - `cat ~/cronenv` /bin/sh
그리고 당신은 이제
sh
cron의 환경을 가진 세션 안에 있습니다. -
cron에 환경을 가져 오십시오
당신은 위의 운동을 건너 뛸 수 있고
. ~/.profile
cron 작업 앞에서 할 수 있습니다.* * * * * . ~/.profile; your_command
-
화면 사용
이 개 솔루션은 여전히 그들에 접근, 실행중인 X 세션에 연결된 환경을 제공하는 것을 실패보다도
dbus
우분투에 예를 들어 등nmcli
(네트워크 관리자) 두 가지 방법 이상에서 작동하지만 여전히 크론에 실패합니다.* * * * * /usr/bin/screen -dm
cron에 위의 줄을 추가하고 한 번 실행 한 다음 다시 끕니다. 화면 세션에 연결하십시오 (screen -r). 화면 세션을 확인하는 경우 (함께 생성 된
ps
그들이 자본에 때때로 (예를 것을 인식)ps | grep SCREEN
)이제는 짝수
nmcli
와 비슷한 것이 실패합니다.
답변
당신은 실행할 수 있습니다 :
env - your_command arguments
빈 환경에서 your_command를 실행합니다.
답변
계정의 셸에 따라
sudo su
env -i /bin/sh
또는
sudo su
env -i /bin/bash --noprofile --norc
에서 http://matthew.mceachen.us/blog/howto-simulate-the-cron-environment-1018.html
답변
6 년 후 답변 : 환경 불일치 문제는 systemd
“타이머”가 cron 대체품으로 해결 한 문제 중 하나입니다 . CLI 또는 cron을 통해 시스템화 된 “서비스”를 실행하든 환경 불일치 문제를 피하면서 정확히 동일한 환경을 수신합니다.
cron 작업이 수동으로 전달 될 때 실패하는 가장 일반적인 문제는 $PATH
cron에서 설정 한 제한적인 기본값 이며, 이는 Ubuntu 16.04에서 발생합니다.
"/usr/bin:/bin"
대조적 으로 Ubuntu 16.04에서 $PATH
설정 한 기본값 systemd
은 다음과 같습니다.
"/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
따라서 시스템 타이머가 더 이상 번거 로움없이 바이너리를 찾을 가능성이 이미 높습니다.
시스템 타이머의 단점은 설정 시간이 조금 더 있다는 것입니다. 먼저 “서비스”파일을 작성하여 실행할 항목을 정의하고 “타이머”파일을 실행하여 스케줄을 정의한 후 타이머를 “활성화”하여 활성화하십시오.
답변
env를 실행하고 stdout을 파일로 경로 재지 정하는 cron 작업을 작성하십시오. “env-“와 함께 파일을 사용하여 cron 작업과 동일한 환경을 작성하십시오.