Het plannen van banen is een essentieel onderdeel van het beheer van servers Linux. Wij namen een blik bij hoe te om banen te plannen bij machine Linux gebruiken cron bevel vroeger. Hier is een alternatief aan cron - bij. Het primaire verschil tussen twee is dat wanneer u een taak gebruikend cron het plant herhaaldelijk zonder de behoefte om opnieuw te programmeren uitvoer. Met bij, enerzijds, is het plannen van een taak slechts voor één enkele uitvoering. Beide bevelen hebben hun gebruik, en ik zou voorstellen dat u een goed inzicht in hen allebei krijgt.
Bekijk hoe te om een taak te plannen om slechts eenmaal gebruiken uit te voeren bij bevel. Zorg eerst ervoor dat bij daemon loopt gebruikend een bevel als dit:
# ps - EF | grep atd
wortel 8231 1 0 18:10? 00:00: 00 /usr/sbin/atd
Als u niet ziet atd het lopen begint het met dit bevel:
# /etc/init.d/atd begin
Zodra daemon met succes is begonnen kunt u plannen bij taak die de twee opties gebruikt - F, voor het uit te voeren dossier, en - v, voor de tijd waarin het zou moeten worden uitgevoerd. Zo als u het shell manuscript wilt uitvoeren shellscript.sh bij 6:30 PM zou u het volgende bevel in werking stellen:
# bij - F shellscript.sh - v 18:30
Herinner dat met bij beveel het manuscript shellscript.sh bij 6:30 PM zal uitvoeren en dan zal het plannen verdwijnen. Zo als dit niet is wat u wenst, bent u beter van het gebruiken cron.
bij het bevel is vrij knap in zoverre dat het sommige orden in het Engels kan nemen als u houdt van. Bijvoorbeeld, kunt u banen plannen eveneens gebruikend de volgende syntaxis:
# bij - F shellscript.sh 10pm morgen
# bij - Fshellscript.sh 2:50 dinsdag
# bij - F shellscript.sh 6:00 11 juli
# bij - F shellscript.sh 2:00 volgende week

























{ 2 comments… read them below or add one }
If you don’t see atd running start it with this command:
# /etc/init.d/atd start
More correctly, if it isn’t running, it probably is not configured to startup when the system is restarted. Which may also keep the above command from working as expected. To correct this, use:
# chkconfig atd --level 234 on
# service atd start
and check again to make sure it is running, if it is, continue with the instructions (which are very good BTW).
I have another followup for you on use of the at command.
I’ve run into situations where I’ve needed a command run every hour BUT I needed the command to run ONLY if the previous run has completed. It might not be hung but it might be very very busy. I don’t mind skipping an hour’s execution if the process is still busy.
When this situation arises, I don’t use cron, I use ‘at’ and the last thing I put in my script is the at command itself to resubmit the job for execution.
Now, even if the job takes three hours, at the top of the following hour, the at command will launch the job as expected without cron jobs bumping into each other.
Yes, there’s ways to put the logic into a script for cron to deal with it but that can also be difficult to maintain and not as obvious (to some) as this approach.
Leave a Comment