Crontab : Planifier des travaux

[ventures]

Bonjour aux Cracks

J'ai un souci avec le script Crontab des planification de travaux par lot sous Aix/unix Version 5.2

Ca fonctionne bien avec ma liste de travaux planifiés, mais depuis lorsque je rajoute un travail supplémentaire dans la liste à une date + heure déterminées, pas moyen de voir démarrer le travail.

J'ai beau arrêter et redémarrer les services du serveur Aix, mais pas de changement, le travail que j'ai rajouté ne tourne pas à la date et heure planifiées, tandis que les autres travaux du Crontab démarrent bien en temps voulu.

Avez-vous expérimenté ce genre de mystère ?

Y a-t-il qlq chose à faire au niveau des droits ?

Toute solution serait bienvenue.

[trax020]

Salut
Peux tu poster l'output de crontab -l pour commencer?

[ventures]

Bonjour,

je vous joins donc le contenu du Crontab sous le nom de l'adminsitrateur 'Root' (avec les droits Root).
Je précise que les travaux planifiés fonctionnent, sauf le travail sous l'intitulé 'Purge du répertoire ADM'.

En effet, je voudrais quotidiennement effacer le contenu du répertoire ADM, et planifie le travail à 5h00 du matin.

Mais malheureusement le travail ne démarre pas du tout.

Si vous avez une idée de ce qui pourrait se passer dans le Crontab, je suis preneur.

[mezziane]

Est ce normal de trouver un "-" entre su et root.
Je pense que c'est la cause.
sinon il faut penser au shell qui va exécuter ton script de purge sinon il faut voir dans le script lui même.
Je pense..

[ventures]

Merci pour votre réponse.
je ne pense pas que cela vient du '-' après la commande SU, car d'autres travaux sont lancés comme ça. mais dans le doute je viens de le supprimer et attendons voir cette nuit à 5h00.

Pour ce qui est du script shell lancé, il fonctionne si je le lance manuellement sur une ligne de commande.

[ventures]

Non le travail n'a pas démarré à 5h00.
Je précise qu'il s'agit d'un serveur AIX/Unix, et qu'apparemment il semblerait que cela soit un peu différent d'un serveur Unix standard.

En effet, les travaux du Crontab nouvellement crées ne démarrent pas et ne sont pas pris en compte avant 2 ou 4 jours une fois le script sauvegardé. Il y aurait sans doute un paramétrage à effectuer côté système (?)

Et malgré cela, mon travail n'a jamais démarré depuis plus d'un mois d'attente.

S'il y a un spécialiste du système Aix/Unix dans ce forum qui aurait expérimenté ce cas, merci pour votre clairvoyance.

[mezziane]

Je comprends pas pourquoi ton script n'a pas fonctionné d'une manière uto mais ...
Ce que je pense, daprès mon expérience avec ce merde crontab, essayez de démarrer le deamon responsable de celui ci ou aller directemement dans le fichier de config qui se trouve dans /etc/sysconfig/...
Pour moi j'ajoute sans problème dans le crontab mais j'ai jamis rencontré ce type de pro.
Dit moi, est ce que les autres scripts ça marche ?

[ventures]

Je vous confirme que tous les scripts shell lancés par le Crontab fonctionnent et peuvent être lancés manuellement.

Sur mes serveurs Aix/unix, il n'y pas de répertoire : /etc/sysconfig/...

Qu'entendez-vous par démarrer le Daemon responsable ?

Je pense qu'il s'agirait de qlq chose dans ce genre, un paramétrage qui dicterait Crontab dans son horloge.

[mezziane]

Bonjour venures,
je veu dire par deamon c'est de pouvoir verifier dans les process que le cron est présent "c'est sur qu'il est présent mais ...."
un lssrc et puis startsrc du service juste pour rafraichir s'il y a quelque chose qui bloque.

[mezziane]

Essayer de voir les log ce qu'il y a dedant d'abor après tu peux voir ce lien :
http://publib.boulder.ibm.com/infoce...s1/crontab.htm
Sinon tu enleve la lmigne que tu as ajouté et tu va l'ajouter par cronadm :
http://publib.boulder.ibm.com/infoce...s1/crontab.htm

[ventures]

L'ajout dans Cronadm n'a pas eu d'effet escompté, le scheduler ne lance toujours pas le job.

Par contre j'ai redémarré le Daemon du scheduler et attend la nuit prochaine pour constater si le Crontab fait bien son travail.

[mezziane]

Je voudrais savoir tes nouvelles à propos de ton problème ?

[ventures]

Bonjour,

Le redémarrage du Daemon du Crontab n'a pas eu l'effet escompté

Mais, la seule et unique modification ayant été faite a été du purger les mails du compte 'root' !
Apparemment, il y aurait eu une saturation au niveau des mails systèmes envoyés au compte 'root' auquel le travail du crontab 'root' est lié.

Ca parait bizarre, mais c'est comme ça, car depuis le travail de purge a bien démarré à 5h00 du matin. Voir log ci-jointe.

Aix nous pose parfois bien des mystères !

Merci pour votre aide etde me dire pourquoi les mails peuvent empêcher de faire tourner un job parmis d'autres qui tournaient sans soucis ?

Sinon, l'incident est bien résolu.

[Mr6]

Juste comme ca, quel est l'intérêt de

Code :

su - root -c

?

L'intérêt d'une crontab par utilisateur est bien de prendre les droits de cet utilisateur pour exécuter un script, donc pas besoin de su en toute logique. Aurais-je raté quelque chose ?

@+
Mr6

[cyril.peyron]

Peut-être un moyen détourné de sourcer le profile de l'utilisateur concerné...

[Escandil]

Bonjour,

Comme suggéré un peu plus haut, vous pouvez remplacer la commande :

Code :

1
2
3
# PURGE DU REPERTOIRE ADM :
0 5 * * 1-6 su - root -c "/logiciels/hra/prd/appli/expl/purges/purge_adm_log"

par

Code :

1
2
3
# PURGE DU REPERTOIRE ADM :
0 5 * * 1-6 "/logiciels/hra/prd/appli/expl/purges/purge_adm_log"

Qui aura le même effet.