Heim > Artikel > Betrieb und Instandhaltung > Gründe, warum Linux Crond nicht ausgeführt wird
Um die CPU-, Speicher- und Lastauslastung des Linux-Systems regelmäßig zu überwachen, habe ich ein Linux-Shell-Skript geschrieben, das regelmäßig E-Mail-Benachrichtigungen sendet. Als ich crond jedoch aufforderte, das Skript zum Senden von E-Mail-Benachrichtigungen regelmäßig auszuführen, stieß ich auf ein Problem. Nachdem ich das Ausführungsskript zu crontab -e hinzugefügt hatte, stellte ich fest, dass das Skript nicht ausgeführt wurde.
Es ist jedoch normal, den Shell-Skriptbefehl (./mimvp-email.sh) manuell auszuführen, da durch die manuelle Ausführung des Skripts standardmäßig die Linux-Umgebungsvariablen abgerufen werden können, diese jedoch nicht über geplante Aufgaben abgerufen werden können erfolgt durch Crontab-Umgebungsvariablen.
Nach der Analyse der Gründe sind die Hauptgründe, warum Crond nicht ausgeführt wird, folgende:
1 Der Crond-Dienst wurde nicht gestartet
ps -ef | grep -v grep | grep crond // 查看crond服务是否运行 service crond start //关闭服务 service crond stop //关闭服务 service crond restart //重启服务 service crond reload //重新载入配置
2 führt keine Crond-Berechtigungen aus
vim /etc/cron.deny-Datei wird verwendet, um zu steuern, welche Benutzer die Funktionen des Crond-Dienstes nicht ausführen können.
Sie können sich selbst aus der Datei löschen oder Root kontaktieren
3. Crontab stellt die Umgebungsvariablen des ausführenden Benutzers nicht bereit
Lösung: Fügen Sie dem Skript Folgendes hinzu Eine Zeile:
./etc/profile
script und crond Es gibt zwei Aspekte des Pfads im Befehl, zum Beispiel:
*/10 * * * * sh /root/script/mysql_files_monitor.sh &
5 Wenn der Das obige Problem löst das Problem nicht. Sie können es erneut versuchen. Finden Sie das Problem:
1) Überprüfen Sie die E-Mail. Während dieses Vorgangs sollte der Benutzer eine E-Mail wie diese erhalten:
vim /var/spool/mail/root
Sie haben E-Mails in /var/spool/mail/root
Schauen Sie sich dort den Crond-Inhalt an
Die Datei ist zu groß zum Öffnen, Sie können die letzten 1000 Zeilen abfangen
tail -n 1000 /var/spool/mail/root > Fügen Sie dem Skript eine Ausgabe zum Debuggen hinzu
Sie können
echo $PATH > /tmp/test.log
im crontab-Skript hinzufügen und mit echo $ vergleichen PATH
6 Wenn beim Ausführen des Skripts im Terminal zu viele Crond-Prozesse vorhanden sind, beenden Sie sie alle und starten Sie den Crond-Dienst neu
#!/bin/bash
für i in $ (ps -elf | grep -v grep | grep crond | awk -F " " ' {print $4}' ); dokill -9 $i
doneVerwenden Sie root, um a auszuführen Neustart, und das Problem ist gelöst:
service crond restart
7. crond verhindert wiederholte Ausführung, bevor das Skript innerhalb des Zyklus abgeschlossen ist
Persönliche Erfahrung: flock -xn my .lock cmd
my.lock ist eine Datei, es kann eine beliebige Datei sein und Sie können eine neue leere Datei erstellenWenn flock die Sperre erhält, führt es den nachfolgenden cmd
-Testvorgang aus :
$1: flock -xn my.lock sleep 20
$2: flock -xn my.lock ls
lockf-Parameter lauten wie folgt
-k: Warten Sie, bis die Dateisperre erhalten ist.
-s: still, sendet keine Informationen, auch wenn die Dateisperre nicht erreicht werden kann.
-t Sekunden: Stellen Sie das Timeout auf Sekunden ein. Wenn die Zeit überschritten wird, wird automatisch aufgegeben.
Bevor Sie die folgende geplante Crontab-Aufgabe ausführen, müssen Sie die temporäre Datei „create.lock“ erhalten. Der Inhalt der geplanten Crontab-Aufgabe lautet wie folgt:
1 */10 * * * * (lockf -s -t 0 /tmp/create.lock /usr/bin/python /home/project/cron/create_tab.py >> /home/project/logs/create.log 2>&1)
Wenn die erste Instanz nicht innerhalb von 10 Minuten ausgeführt wird, wird die zweite Instanz nicht ausgeführt. Früher habe ich dieses Problem durch Shell-Skripte gelöst, z. B. durch die Verwendung einer while...do-Schleife und deren anschließende Ausführung im Hintergrund. Später stellte ich jedoch fest, dass es einfacher ist, die Flock- oder Lockf-Methode zu verwenden.
Anbei finden Sie die Verwendung von flock unter Linux:
flock (util-linux 2.13-pre7)
Usage: flock [-sxun][-w #] fd#
flock [-sxon][-w #] file [-c] command...
-s --shared Get a shared lock
#共享锁,在定向为某文件的FD上设置共享锁而未释放锁的时间内,其他进程试图在定向为此文件的FD上设置独占锁的请求失败,而其他进程试图在定向为此文件的FD上设置共享锁的请求会成功
-x --exclusive Get an exclusive lock
#独占或排他锁,在定向为某文件的FD上设置独占锁而未释放锁的时间内,其他进程试图在定向为此文件的FD上设置共享锁或独占锁都会失败。只要未设置-s参数,此参数默认被设置
-u --unlock Remove a lock
#手动解锁,一般情况不必须,当FD关闭时,系统会自动解锁,此参数用于脚本命令一部分需要异步执行,一部分可以同步执行的情况
-n --nonblock Fail rather than wait
#为非阻塞模式,当试图设置锁失败,采用非阻塞模式,直接返回1,
-w --timeout Wait for a limited amount of time
#设置阻塞超时,当超过设置的秒数,就跳出阻塞,返回1
-o --close Close file descriptor before running command
-c --command Run a single command string through the shell 执行其后的comand
-h --help Display this text
-V --version Display version
举个例子执行如下脚本:
每天23:30的时候执行一个脚本,但是执行前必须要获得排他文件锁,否则无法执行命令
1 30 23 * * * flock -xn /tmp/test.lock -c '/usr/local/php test.php'
8、; 和 && 区别
“;” 和 “&&”是有区别的
“;”:不管cmd1执行的结果如何,都执行cmd2
“&&”:只有cmd1执行返回的结果是成功的,才执行cmd2
cmd1 && cmd2; cmd3
- cmd1 is executed, if it succeeds, then execute cmd2. and then cmd3 (regardless of cmd2 success or not)
- cmd1 is executed, if it fails, then cmd3 (cmd2 won't be executed)
9、如果遇到shell语法错误
Syntax error: "(" unexpected
解决方法:
需指定shell解释器命令:SHELL=/bin/bash(请参见上面 crontab编辑示例 SHELL=/bin/bash)
或者参见: LINUX - BASH Syntax Error
如果遇到路径错误
在 /var/spool/crontab/yanggang 中,添加了如下命令,在日志文件 /var/spool/mail/yanggang 中提示找不到 xxx.sh 路径
30 * * * * /home/barry/top800/top10/top10_fruits/top10_all.sh
或
30 * * * * bash /home/barry/top800/top10/top10_fruits/top10_all.sh
这是因为你在crontab中使用了绝对路径执行脚本 top10_all.sh,因此在脚本 top10_all.sh 中引用的其它脚本也都需要使用绝对路径,才能被crontab找到并执行。
那么该如何避免绝对路径呢,推荐采用如下格式:
30 * * * * cd /home/barry/top800/top10/top10_fruits/ && ./top10_all.sh(推荐用此方式)
先进入该目录,然后在执行脚本;否则,执行脚本中的其它脚本都需要加绝对路径
参考推荐:
CentOS 7.2上 crontab 计划任务
linux定时运行命令脚本——crontab
CentOS crontab 定时任务不执行的解决
WordPress定时任务(wp-cron.php)造成主机CPU超标解决办法。
Das obige ist der detaillierte Inhalt vonGründe, warum Linux Crond nicht ausgeführt wird. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!