답변:
cron은 더 나은 표준 방법이므로 사용하십시오. 적어도 이것이 정기적으로 실행되는 것이라면 (분 단위로 패치 한 것뿐만 아니라). cron더 깨끗하고 표준적인 방법입니다. 터미널에서 분리 된 쉘을 실행하기 때문에 우연히 종료되며 다른 프로세스에 대한 의존성 문제가 없습니다.
리소스 관련 : CPU : 두 프로세스 모두 휴면-휴면시 CPU를 낭비하지 않습니다. cron일을 확인하기 위해 더 자주 깨어납니다.하지만 어쨌든 그렇게합니다. 그리고 이것은 무시할만한로드이며, 대부분의 데몬은 가끔 깨어납니다. 메모리 : cron이 프로세스에 관계없이 실행 중일 수 있으므로 오버 헤드가 전혀 없습니다. 그러나 cron은 스크립트가 호출 될 때만 셸을 시작하지만 스크립트는 메모리에로드 된 상태로 유지됩니다 (쉘 변수에 모든 것을로드하지 않는 한 환경-몇 킬로바이트의 bash 프로세스).
리소스는 중요하지 않습니다.
이미 좋은 답변 cron과 sleep성능이 있지만 기능 비교를 추가하고 싶습니다.
프로 cron:
프로 sleep:
cron은 어떤 종류의 트리거를 사용하거나 다른 트리거보다 효율적으로 작동합니까?
나는 살펴 보았다 cat /proc/`pidof crond`/stack. 몇 번 연속 인쇄 crond하여 hrtimer_nanosleep에서 잠을자는 것을 알 수 있습니다.
>cat /proc/`pidof crond`/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffffsleep 유틸리티는 동일한 시스템 호출을 사용합니다.
>sleep 100 &
[1] 12761
>cat /proc/12761/stack
[<ffffffff810a0614>] hrtimer_nanosleep+0xc4/0x180
[<ffffffff810a073e>] sys_nanosleep+0x6e/0x80
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff두 유틸리티 ( crond& sleep) 모두 CPU 사용률이 낮아야 한다고 가정 하고 모방해야 할 경우 cron명확하게 사용할 수 있습니다 sleep.
최신 정보. crond의 활동 을 관찰하는 것이 좋습니다
strace -p `pidof crond`당신이 찾고있는 주요 차이점은 cron끊임없이 실행되지 않는다는 것입니다. 에 설명 된대로 man cron:
cron then wakes up every minute, examining all stored crontabs, check‐
ing each command to see if it should be run in the current minute.
When executing commands, any output is mailed to the owner of the
crontab (or to the user named in the MAILTO environment variable in the
crontab, if such exists). The children copies of cron running these
processes have their name coerced to uppercase, as will be seen in the
syslog and ps output.다시 말해, cron1 분에 한 번만 시작되며 실행 여부를 테스트합니다. 반면에 수면 접근 방식은 실제 sleep명령, 쉘, 터미널 및 while(또는 무엇이든) 루프가 동시에 실행되어야합니다.
동일한 수의 프로세스를 시작하더라도 cron더 나을 것입니다. 자신의 직업에 능숙한 사람들이이 내용을 정확하게 기록합니다. 단순한 쉘 루프보다 더 나은 작업을 수행해야합니다.
차이점은 잠자기해야하는 스크립트를 더 많이 추가 할 때 예약 된 스크립트를 깨우고 실행 한 다음 다음 실행까지 닫는 단일 프로세스 (크론) 대신 대기중인 더 많은 프로세스를 끝내게된다는 것입니다. Cron은 시간에 다른 스크립트를 실행하는 데 특화된 하나의 프로세스를 허용하며, cron을 사용하면 실행해야 할시기, 요일 또는 월, 특정 시간 또는 5 분마다 비교적 자유롭게 예약 할 수 있습니다.
* 이걸 다시 보면서 cron의 또 다른 이점을 생각하게되었습니다. 그러면 정기적으로 실행되는 모든 스크립트가 한 곳에 있으며 언제 어디서 얼마나 자주 실행되는지 쉽게 확인할 수 있습니다. 그렇지 않으면 개별 스크립트를 확인해야합니다.
이미 잘 알고 더 많은 대답이 있지만, 나는 단지 sleep다른 변수의 함수와 같이 변수 시간 동안 프로세스를 동결시킬 수 있다는 것을 지적하고 싶었습니다 .
배터리 잔량을 확인하기 위해 스크립트를 작성 중이고 notify-send사전 정의 된 위험 수준 미만인 경우 sleep배터리를 점검하는 대신 현재 배터리 잔량의 백분율로 스크립트 를 만들 수 있습니다. 내가 마지막으로 확인했을 때 80 %라는 것을 알았을 때에도 cron의 도움으로 1-2 분.
Battery_notify.sh
#!/bin/bash
CRIT=15
while true; do
# current battery level
BAT_LEVEL=`acpi -b |grep -Eo "[0-9]+%"|grep -Eo "[0-9]+"`
interval=$((($BAT_LEVEL -$CRIT) * 120)) # loose estimate of backup time for each percentage of battery charge.
# Is AC plugged in?
state=`acpi -b |grep -Eo "[A-Za-z]+harging"`
#only notify if not Plugged in
if [ "$state" = "Discharging" ] ; then
# is battery below CRIT level?
if [ $BAT_LEVEL -le $CRIT ]; then
aplay ~/apert.wav &
notify-send "Battery-Low!!!" -i /home/bibek/batt.png -t 900
sleep 100 # nag me each 100 secs untill I plug the thing
else
sleep $interval
fi
else
# if plugged in sleep
if [ $BAT_LEVEL -le $CRIT ]; then
sleep $interval
else
# to check if the AC is unplugged before battery gains charge above CRIT.
sleep 100
fi
fi
done