Que signifie «ligne 19: 12364 tué» dans le message d'erreur crontab?

J'ai une tâche crontab quotidienne:

50 1 * * * sh /my_path/daily_task.sh > /tmp/zen_log 2>&1

Ce script shell daily_task exécutera certains scripts python et produira un fichier de données.

Et ça échoue pendant deux nuits. Mais quand je suis arrivé le matin, exécutez les scripts python manuellement, j'ai reçu le fichier de données. Ou je mets un nouveau crontab qui ne fixe que la date 0 10 * * *, et ce crontab réussit aussi.

Hier, j'ai mis > /tmp/zen_log 2>&1la tâche cron pour obtenir un message d'erreur.

Et ce matin, j'ai reçu ce message d'erreur dans zen_log:

/my_path/daily_task.sh: line 19: 12364 Killed /usr/local/bin/python2.7 my_python_script.py 2 mix > mix_hc_$datestamp 2>&1

Il semble qu'un processus ait été tué? Mais qu'est-ce line 19: 12364 Killedque cela signifie exactement ?

PS:

Aujourd'hui, il y a une minute, lorsque j'exécute manuellement le script python, j'ai obtenu: /usr/local/bin/python2.7 my_python_script.py 2 mix > mix_hc_$datestamp 2>&1 Killed

bash cron

— Zen
source

Que contient line 19le script? Peut-être que la publication de votre script nous aidera à vous fournir une réponse.

— devnull

line 19est/usr/local/bin/python2.7 my_python_script.py 2 mix > mix_hc_$datestamp 2>&1

— Zen

Pouvez-vous mettre à jour votre question avec le contenu de daily_task.sh? Il est difficile de comprendre pourquoi il échoue, 1:50 ammais réussit à ce jour 10 amavec les informations.

— devnull

Vérifiez également le contenu de /var/log/messagesJe me demande si votre script crée une erreur de mémoire insuffisante (MOO) et est tué. Votre système a-t-il tendance à exécuter d'autres scripts / applications / travaux gourmands en ressources système pendant les heures nocturnes par rapport aux heures du matin?

— devnull

@DevNull, j'ai vérifié le journal du noyau, maintenant je suis sûr que ce script a occupé trop de mémoire et le noyau l'a tué.

— Zen

Souvent, lorsque des applications sont en cours killed, il est toujours judicieux de jeter un coup d'œil à votre /var/log/messagesfichier pour voir si le noyau est en train de tuer le processus. Le déclencheur le plus courant (d'après mon expérience) a toujours été dû à des erreurs de mémoire insuffisante (OOM), car mon entreprise utilise principalement des applications java, il est assez fréquent que les développeurs publient une mauvaise mise à jour de code qui déclenche un événement OOM .

Planifier des tâches lorsque votre système d'exploitation dispose des ressources les plus disponibles est probablement la raison pour laquelle il réussit dans les créneaux horaires AM et non dans le PM lorsque la plupart des gens aiment planifier des tâches système taxantes. Les solutions simples à cela consistent à augmenter les ressources de vos systèmes, à restreindre les ressources allouées à votre code ou à vous déplacer lorsque vos travaux sont planifiés afin qu'ils n'entrent pas en conflit.

— devnull
source

Juste une note supplémentaire que par défaut, ubuntu affiche le messagesdans syslog au lieu de/var/log/messages

— oak