Dois-je utiliser cron.hourly ou crontab?

Il semble que toutes les suggestions pour utiliser / planifier des awstats se font via crontab, comme 0 * * * * /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=mysite -update >/dev/nullceci : (lancer awstats toutes les heures).

Cependant, si je vérifie crontab -l, il indique que crontab est vide pour mon utilisateur.

Cependant, lorsque je vérifie le /etc/cron.hourly, j'ai un fichier awstats avec les éléments suivants:

#!/bin/bash
exec /usr/share/awstats/tools/awstats_updateall.pl now         -configdir="/etc/awstats"           -awstatsprog="/usr/share/awstats/wwwroot/cgi-bin/awstats.pl" >/dev/null
exit 0

Juste pour vous faire savoir, mon awstats est bien mis à jour, il crée ses rapports, et tout va bien.

L'exécution d'une commande crontab crée-t-elle une entrée dans le dossier cron spécifié? (c'est-à-dire cron.hourly ou cron.daily, etc.)? Ou ne sont-ils pas liés? S'ils sont liés, pourquoi mon utilisateur est-il sans entrée crontab?

linux cron awstats

— boisson pétillante
source

crontab -eest la manière traditionnelle de créer une crontab. Je trouve que c'est maladroit et démodé, mais les gens l'utilisent toujours.

/etc/cron.hourly, y compris cron.daily, cron.weekly& /etc/cron.d, etc. sont fournis par la plupart des distributions Linux car ils sont pratiques et fonctionnent bien avec les outils d'automatisation tels que les gestionnaires de paquets et les systèmes de gestion de configuration. Il est très facile pour un gestionnaire de paquets de déposer un fichier par /etc/cron.hourly/foorapport au scriptage et à l'édition d'une crontab existante. La modification d'un fichier par programme via un gestionnaire de packages peut corrompre le fichier, ajouter des entrées en double, supprimer la mauvaise ligne, bousiller les commentaires, etc. Voir Editfiles Considered Harmful pour une discussion, car ce problème existe depuis un certain temps.

L'exécution d'une commande crontab crée-t-elle une entrée dans le dossier cron spécifié?

No. /etc/cron.daily/fooest créé par le gestionnaire de packages ou créé à la main. Il n'est pas créé lorsque vous exécutez la commande crontab. crontab -eva créer le crontab sous /var, comme /var/spool/cron/root.

Je préfère /etc/cron.$period/fooet /etc/cron.dparce que cette hiérarchie est soignée et organisée, et il est facile de créer un script pour mon système de gestion de la configuration. /etc/crontabest également disponible sur Linux, mais il est un peu monolithique et difficile à éditer par programme. Des systèmes tels que le support FreeBSD /etc/crontabet /etc/periodic.

— Stefan Lasiewski
source

Merci pour votre réponse, je la préfère également, car j'ai l'habitude de déposer des fichiers de configuration dans des dossiers .d (ie conf.d, etc.)!

— boisson gazeuse le

Je ne peux qu'être d'accord là-dessus. Je préfère également utiliser le système /etc/crontablorsqu'il s'agit d'exécuter des taks système plutôt que d'utiliser crontab de root. De cette façon, on peut facilement savoir ce que fait le système sans creuser dans la crontab de chaque utilisateur.

— Spack du

Je suis d'accord avec cette réponse. Mentionnez peut-être d'autres différences: /etc/cron.$period/ contient des scripts autosuffisants qui sont exécutés par l'utilisateur root. OTOH /etc/cron.d/ contient des fichiers include au crontab -eformat. Enfin, / etc / cron * est destiné aux scripts exécutés en root, tandis qu'il crontab -eest disponible pour tous les utilisateurs.

— Nils Toedtmann

La crontab -ecommande est maladroite par défaut. J'ai donc créé un script appelé ctequi exécute deux commandes: export EDITOR=geditet ensuite crontab -el'éditeur est plus facile à utiliser.

— SDsolar