Question travail cron occasionnellement ne fonctionnant pas


j'ai un CentOS 6.6 serveur 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'une des tâches de sauvegarde planifiée pour une exécution quotidienne 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 au même moment s’exécutent sans problème.

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

crond ignore simplement l'un des multiples travaux censés s'exécuter à un moment donné. Cela ne se produit que sporadiquement.

J'ai lu dans d'autres endroits que des personnes parlaient d'ajouter une ligne vide à la fin du fichier crontab. Le travail qui échoue parfois est en fait à la dernière ligne de mon fichier crontab. 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)

Regardez comment OTHERJOB toujours courir pendant que Apr 1  pg_backup.sh n'a même pas été exécuté.

J'ai déjà essayé de redémarrer Crond mais cela continue. Ceci affecte plusieurs serveurs avec la même version de RPM OS, noyau et cron.

Il existe une version plus récente de cronie (1.4.12), mais sa mise à niveau n’est pas une option, car nous utilisons déjà la dernière version disponible pour Centos 6.6.

Je suis passé par le journal des modifications pour toutes les versions de Cronie après la mienne (1.4.4) et je ne semble pas avoir trouvé de solution à ce problème particulier. Également vérifié tous les messages de validation.


8
2018-04-02 15:10


origine


Bon dépannage. Pourquoi ne pas essayer d’ajouter une dernière ligne noop (echo >/dev/null par exemple)? - Belmin Fernandez
Y at-il une de vos commandes jeter erreur. cela pourrait éventuellement arrêter le script. J'ai eu une expérience similaire avec les scripts init.d. - hardik
Quelle est la rapidité d'exécution de chacun des travaux? Si le travail que vous démarrez toutes les minutes dure deux minutes, cela peut poser problème. Mais si cela se termine en deux secondes, alors 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 que OTHERJOB était traité correctement alors que pg_backup.sh ne s'exécutait tout simplement pas. - Luis
Vérifier /var/log/audit/audit.log. - Michael Hampton♦


Réponses:


Le cron original demandait que chaque entrée se termine par une nouvelle ligne, alors 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. 

6
2018-05-19 17:37





C'est la première réponse qui vient avec le texte de recherche cron error getpwname failed alors j'ai pensé poster 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.


2
2018-02-23 17:54





nous utilisons sssd pour l'authentification à distance. crond doit vérifier la disponibilité des utilisateurs avant les travaux en cours et le fait toutes les 60 secondes. sssd défaut client_idle_timeout est 60 secondes. donc nous avons eu une condition de concurrence entre sssd et crond

Nous ne sommes allés au fond de ce problème que sur la version 1.4.4-14 crond a commencé à être un peu plus bavard à propos de 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

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

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

Problème: sssd_be terminé par SIGKILL car getpwnam () a renvoyé EPIPE   (c.-à-d. un tuyau cassé) peut faire en sorte que crond ignore les entrées de travail cron.

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

client_idle_timeout = 75

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


1
2018-06-25 13:22