travail cron parfois pas en cours d'exécution

J'ai un CentOS 6.6serveur avec les packages suivants installés:

crontabs-1.10-33.el6.noarch
cronie-1.4.4-12.el6.x86_64
cronie-anacron-1.4.4-12.el6.x86_64
kernel-2.6.32-504.3.3.el6.x86_64

Parfois, l'un des travaux de sauvegarde planifiés pour s'exécuter quotidiennement ne s'exécute tout simplement pas. Le script n'est même pas appelé selon /var/log/cron.log. Il est intéressant de mentionner que d'autres travaux planifiés pour s'exécuter exactement en même temps s'exécutent sans aucun problème.

Je ne peux pas reproduire le problème et n'ai repéré aucun motif dessus. Si je ne fais rien, le travail s'exécute correctement le lendemain, comme prévu.

crond ignore simplement une seule des multiples tâches qui sont censées s'exécuter à un moment donné. Cela ne se produit que sporadiquement.

J'ai lu dans quelques autres endroits des gens qui parlaient d'ajouter une ligne vide à la fin du crontabfichier. Le travail qui parfois ne s'exécute pas est en effet à la dernière ligne de mon crontabdossier. Je n'ai trouvé aucune confirmation qu'il s'agit d'un bug réel ou connu.

# tail -2 /var/spool/cron/postgres
*  * * * * OTHERJOB
0 21 * * * /pg_backup.sh

C'est tout ce que j'ai dans mon /var/log/cron.log

Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19394]: (root) CMD (OTHERJOB)
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19418]: (postgres) CMD (/pg_backup.sh)
Mar 31 21:01:02 SERVERNAME [cron.info] CROND[20062]: (root) CMD (OTHERJOB)

Apr  1 21:00:02 SERVERNAME [cron.info] CROND[31349]: (root) CMD (OTHERJOB)
Apr  1 21:01:01 SERVERNAME [cron.info] CROND[32080]: (root) CMD (OTHERJOB)

Voyez comment OTHERJOBtoujours exécuter pendant que on Apr 1 pg_backup.shn'était même pas exécuté.

J'ai déjà essayé de redémarrer crondmais cela continue. Cela affecte plusieurs serveurs avec la même version du système d'exploitation, du noyau et des cronRPM.

Il existe une version plus récente de cronie( 1.4.12), mais la mettre à niveau n'est pas une option car nous utilisons déjà la dernière version disponible pourCentos 6.6

J'ai parcouru le journal des modifications pour toutes les cronieversions après le mien ( 1.4.4) et je n'ai pas trouvé de solution à ce problème particulier. Également vérifié tous les messages de validation .

— Luis
source

Bon dépannage. Pourquoi ne pas essayer d'ajouter une dernière ligne noop ( echo >/dev/nullpar exemple)?

— Belmin Fernandez

Y a-t-il une de vos commandes qui génère une erreur. cela pourrait éventuellement arrêter le script. J'ai eu une expérience similaire avec les scripts init.d.

— hardik

À quelle vitesse chacun des travaux se termine-t-il? Si le travail que vous démarrez toutes les minutes s'exécute pendant deux minutes à chaque fois, cela peut être un problème. Mais si cela se termine en deux secondes, ce n'est probablement pas un problème.

— kasperd

Le travail qui s'exécute toutes les minutes (OTHERJOB) se termine en quelques secondes. Mais ce n'est pas le problème. J'ai seulement ajouté OTHERJOB aux journaux ci-dessus pour montrer que crond était en cours d'exécution et OTHERJOB a été traité correctement alors que pg_backup.sh ne fonctionnait tout simplement pas.

— Luis

Vérifiez /var/log/audit/audit.log.

— Michael Hampton

Réponses:

Le cron d'origine exigeait que chaque entrée se termine par une nouvelle ligne, donc oui, parfois, vous avez besoin d'une ligne vierge ou de quelque chose à la fin.

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Certaines versions l'ont corrigé ou émettent un avertissement, par exemple Ubuntu Maverik (10.10): crontab regardez la section de diagnostic en bas qui indique qu'un avertissement sera écrit dans syslog.

DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline  character.
       If  the last entry in a crontab is missing a newline (ie, terminated by
       EOF), cron will consider the crontab (at  least  partially)  broken.  A
       warning will be written to syslog.

— Brian
source

Ceci est la première réponse qui arrive avec le texte de recherche cron error getpwname failed, j'ai donc pensé publier la cause de mon problème:

J'utilisais / etc / crontab mais j'avais oublié de mettre l'utilisateur devant la commande.

c'est à dire,

*/5   *  *  *  * /bin/bash <filename>

Au lieu de

 */5   *  *  *  * root /bin/bash <filename>

Cela a donné la même erreur, allez comprendre.

— Aaron R.
source

nous utilisons sssdpour l'authentification à distance. cronddoit vérifier les utilisateurs disponibles avant d'exécuter les travaux et il le fait toutes les 60 secondes. sssdla valeur par défaut client_idle_timeoutest de 60 secondes. nous avons donc eu une condition de concurrence entre sssdetcrond

Nous ne sommes arrivés qu'au fond de ce problème car sur la version 1.4.4-14crond a commencé à être un peu plus bavard sur certaines erreurs.

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <tmraz@redhat.com> - 1.4.4-14
- add log message when getpwnam fails

Après la mise à jour vers cette version, nous avons commencé à voir l'erreur ci-dessous en même temps qu'un travail ne s'exécutait pas:

[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe

qui nous a amenés à cela: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

et enfin à ceci: https://access.redhat.com/solutions/1125133

Problème: sssd_berésilié avec SIGKILL en raison du retour de getpwnam () EPIPE (c'est-à-dire un tuyau cassé) peut faire en sorte que crond saute silencieusement les entrées de tâche cron.

La solution suggérée sur le lien ci-dessus était d'ajouter la ligne ci-dessous à /etc/sssd/sssd.conf:

client_idle_timeout = 75

Le changement ci-dessus a résolu le problème pour nous et cron ne saute plus les travaux.

— Luis
source