Crontab et run-parts [résolu]

Support Debian
#1

Je suis en train de configurer un serveur de sauvegardes incrémentales avec rsync et cron, sur une Etch, en prenant l’exemple donné sur linux-pratique N°32 du 11-12 2005 et j’aimerai savoir si mon /etc/crontab que j’ai du adapter à run-parts est valable

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root


*/15 * * * *    root    run-parts --report /etc/cron.hourly && run-parts --report /etc/cron.daily && run-parts --report /etc/cron.weekly && run-parts --report /etc/cron.monthly
0  *  * * *     root    rm -f /var/spool/cron/lastrun/cron.hourly
0  5  * * *     root    rm -f /var/spool/cron/lastrun/cron.daily
0  4  * * 1     root    rm -f /var/spool/cron/lastrun/cron.weekly
0  3  1 * *     root    rm -f /var/spool/cron/lastrun/cron.monthly

et par la même occasion si /var/spool/cron/lastrun/ est créé par cron sous Etch car je ne le trouve pas.

#2

attends, je ne comprends pas, tu as le paquet anacron qui fait les run-parts lui même:

[code]# /etc/crontab: system-wide crontab

Unlike any other crontab you don’t have to run the `crontab’

command to install the new version when you edit this file

and files in /etc/cron.d. These files also have username fields,

that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

m h dom mon dow user command

17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

[/code]pourquoi tu es allé bidouiller le crontab toi même ?

#3

Je suis encore un peu frais dans l’utilisation de cron.
D’après la recette, il est possible qu’un utilisateur puisse enregistrer un fichier pourri, qui se retrouvera dans toutes les sauvegardes pour une histioire de date d’enregistrement. Il est donc proposé un crontab qui corrige ce pb et qui nettoie les /var/spool/cron/lastrun, mais avec run-crons.

Et dans le man 5 crontab, il est dit :
EXEMPLE DE FICHIER SYSTÈME CRON
Le champ utilisateur est présent, il est utilisé comme dans le fichier /etc/crontab.
# /etc/crontab: crontab du système
# A la différence des autres crontabs, vous n’avez pas besoin d’exécuter
# la commande crontab pour installer la nouvelle version quand vous
# modifiez ce fichier. Ce fichier possède aussi un champ utilisateur que
# les autres crontabs n’ont pas.

   SHELL=/bin/sh
   PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

   # m h dom mon dow utilisateur commande
   42 6 * * *        root    run-parts --report /etc/cron.daily
   47 6 * * 7        root    run-parts --report /etc/cron.weekly
   52 6 1 * *        root    run-parts --report /etc/cron.monthly
   #
   # Supprime l'invocation d'anacron, puisque cela est maintenant géré par
   # un fichier dans /etc/cron.d

J’avoue que je suis un peu largué entre les différentes distribs!

Est-ce que la crontab système d’origine m’éviterait tout autant ce problème ou dois-je en créer une autre pour root?[/code]

#4

bon, ben écoutes, tu m’apprends qu’anacron est obsolète.
Pour le reste, il me semble que ton instruction unique sur une seule ligne ne colle pas. Mais bon, tu as l’article sous les yeux.
Enfin je ne vois pas ce que tu essayes de faire: tout est plutot bien configuré par debian de ce coté là.

#5

[quote=“maufab”]Je suis encore un peu frais dans l’utilisation de cron.
D’après la recette, il est possible qu’un utilisateur puisse enregistrer un fichier pourri, qui se retrouvera dans toutes les sauvegardes pour une histioire de date d’enregistrement. Il est donc proposé un crontab qui corrige ce pb et qui nettoie les /var/spool/cron/lastrun, mais avec run-crons.
[/quote]

C’est pas cron qui est fautif, c’est la façon de faire tes sauvegardes incrémentales qui ne semble pas au point :p!

 test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

Cela fait l’un ou l’autre, pas les deux. Donc il n’y a aucun besoin d’aller triffouiller le fichier /etc/crontab, mais plutot d’aller regarder les /etc/cron* comme te l’a proposé mattotop.

#6

Tout compte fait, j’ai créé une crontab root :

MAILTO=root

# m h dom mon dow  command
#*/15 * * * *     run-parts --report /etc/cron.d/
0  *  * * *       run-parts --report /etc/cron.d/cron.hourly
0  5  * * *       run-parts --report /etc/cron.d/cron.daily
0  4  * * 1       run-parts --report /etc/cron.d/cron.weekly
0  3  1 * *       run-parts --report /etc/cron.d/cron.monthly

et j’ai transféré tous mes scriptrs dans /etc/cron.d/ en laissant tranquille la crontab système.

Que veut dire le double pipe dans la crontab système par défaut? test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily

Par contre, je ne trouve pas comment empêcher le démarrage d’un processus avant que le précédent ne soit terminé, comme sous la Gentoorm -f /var/spool/cron/lastrun/cron
C’est implémenté par défaut chez Debian?

#7

|| est un bête “ou” en shell.
-> vérifier qu’anacron existe, sinon, lancer le run-parts.