Désactivation robuste de cron spécifique. {Script horaire, quotidien, hebdomadaire}

25

Sur divers systèmes que j'administre, il existe des scripts cron qui s'exécutent via la disposition couramment utilisée /etc/cron.{hourly,daily,weekly}. Ce que je veux savoir, c'est s'il existe une fonctionnalité commune de «désactiver ce script».

De toute évidence, la simple suppression d'un élément d'un répertoire donné le désactivera, mais je recherche une solution plus permanente. La suppression /etc/cron.daily/slocatefonctionnera pour désactiver la nuit updatedbsur ma machine domestique (où je ne l'utilise jamais slocate), mais la prochaine fois que je mettrai à niveau le paquet slocate, je suis presque sûr qu'il réapparaîtra.

Les deux distributions qui m'intéressent le plus sont Gentoo et OpenSUSE, mais j'espère qu'il existe un mécanisme largement implémenté. Les deux distributions comme je les utilise utilisent vixie-cron (pas sûr que ça compte).

cron cron.daily

— benizi
source

45

Vous devriez pouvoir chmod -x scriptnamedésactiver un script mais laisser le fichier en place.

— En pause jusqu'à nouvel ordre.
source

5

Cela pourrait ou non être annulé par le système de gestion des packages. Vous pouvez rendre cela plus robuste en le faisant chattr +i scriptnameaprès le chmod.

— mc0e

@ mc0e merci de m'avoir enseigné les fichiers immuables, mais comme quelqu'un l'a déjà dit , ils font peur . Si jamais j'oublie ce que j'ai fait, cela peut entraîner des ennuis très frustrants.

— Jonathan Y.

2

@JonathanY .: C'est à cela que lsattrsert - pour supprimer l' effrayant (il répertorie les atteibutes d'un fichier).

— pause jusqu'à nouvel ordre.

1

DW bien sûr, mais savoir regarder les attributs de fichier lorsque quelque chose se passe inexplicablement (tout comme dans le fil auquel j'ai lié) est le vrai coup de fouet ici.

— Jonathan Y.

@JonathanY. Alors maintenant, vous savez. :-) Dans tous les cas, je pense que le bit 'effrayant' dans ce fil lié fait référence à un bug pacman, pas à chattr lui

— mc0e

9

run-parts n'exécute pas de travaux qui ont un point dans leur nom, donc

mv /etc/cron.d/job /etc/cron.d/job.disabled

fera l'affaire.

— chrisv
source

1

Malheureusement, cela aura le même problème lors de la mise à niveau du programme - il vérifiera si le travail cron existe, et comme il n'existe pas sous son nom d'origine, il sera recréé.

— Jenny D dit Réintégrer Monica

2

Revenir lors de la mise à niveau du programme est un effet secondaire de l'outil de package utilisé, ne peut pas être résolu par des moyens simples et n'est pas la faute de Cron. Certains systèmes de packages nuke et pavent les fichiers précédents, d'autres diffèrent les nouveaux et les anciens et vous demandent s'il y a des changements à réviser. Quoi qu'il en soit, les mises à jour qui produisent un comportement involontaire devraient être frustrantes, mais elles font partie intégrante de l'administration des systèmes Unix à ce stade. Il y a tout simplement trop de packages qui se déplacent trop rapidement pour examiner régulièrement tous les changements pour leur impact dans chaque environnement individuel.

— peelman

Dans Debian, il y a une notion de détournement de fichier - c'est-à-dire que vous pouvez renommer efficacement le fichier alors qu'il est toujours géré par le gestionnaire de paquets. Peut-être qu'un mécanisme similaire existe dans Gentoo et / ou SUSE?

— Bass

9

cron.dailyEst généralement invoqué via /etc/crontabune ligne comme par exemple

run-parts --report /etc/cron.daily

man run-parts vous donne les options.

run-parts --test /etc/cron.daily montre quels travaux sont exécutés sans les exécuter.

Je préfère créer un sous-répertoire «Disabled» et y déplacer mes emplois.

Dans tous les cas, si vous mettez à jour un package, il est probable que le travail se remette en place ou que les bits «x» supprimés soient restaurés

— Peter
source

1

Vous pouvez supprimer le package slocate si vous ne l'utilisez jamais.

— Maxfer
source

Ce n'était qu'un exemple, mais toujours un bon conseil, merci. (Je pensais que quelque chose pouvait dépendre de slocate, mais rien ne semble l'être.)

— benizi

Supprimez slocate et installez mlocate à la place. Bien mieux.

— mc0e

1

Si vous utilisez cfengine ( https://cfengine.com/ ), vous pouvez le faire en désactivant. Vous venez d'écrire un fichier de promesse pour un groupe d'hôtes et il s'appliquera lors de la prochaine exécution de cfagent. Faire cela avec une marionnette ou un chef ou quoi que ce soit devrait également être assez simple.

— natxo asenjo
source

Intéressant. Je n'ai rencontré des outils de gestion de configuration que de manière très tangentielle. Je cherchais une solution générale "J'ai un système arbitraire de type Unix".

— benizi

1

Le /etc/cron.daily et. Al. les scripts sont exécutés par un script appelé run-parts. Ce script varie. Par exemple, le commutateur --test mentionné ci-dessus ne se trouve pas sur la machine que j'utilise en ce moment.

Run-parts est un script bash. C'est un outil généralement utile pour exécuter tous les scripts dans le répertoire qu'il donne en argument. Il se trouve généralement dans / usr / bin / run-parts.

Il a un enchevêtrement de logique pour décider quoi exécuter. Ce code contient la réponse à votre question, mais il varie également. Vous devez donc lire le code pour être sûr.

Dans la version que je regarde, il a une logique qui, lorsque vous travaillez sur le répertoire <foo>, vérifie <foo> /jobs.deny. Si cela existe, il refuse d'exécuter tout script mentionné dans ce fichier sur une ligne, seul. En supposant que vous ayez cette fonctionnalité, elle est géniale car elle continuera à fonctionner lorsque le package qui installe est installé ou mis à niveau.

— Ben Hyde
source

0

Si vous traitez avec RHEL et ses dérivés (qui fournit le crontabspackage), vous pouvez explicitement désactiver un travail en mettant son nom dans le jobs.denyfichier.

Depuis la page de manuel crontabs / run-parts :

L'exécution de fichiers peut être autorisée ou refusée en créant le fichier jobs.allow ou jobs.deny qui fonctionnait de la même manière que les autres fichiers de configuration allow / deny. Le fichier doit être créé dans le répertoire spécifié.

L'exemple /etc/cron.daily/jobs.deny pourrait contenir par exemple 0logwatch qui interdit l'exécution de ce script.

— shodanshok
source

-1

Si vous ne voulez pas non plus les user-crontabs, désactivez simplement crond dans votre liste de services.

Dans Debian et les versions basées sur Debian, il s'agit simplement de supprimer le lien symbolique du /etc/rcX.d approprié (pour le niveau d'exécution X).

Je ne sais pas comment vous gérez les services dans SUSE ou Gentoo.

— jishi
source

4

C'est juste une mauvaise idée. La désactivation complète de cron désactivera les tâches de maintenance utiles telles que logrotate, updatedb, éventuellement les mises à niveau sans assistance et les sauvegardes standard.

— Tobu

Updatedb est exactement la tâche que j'essaie de désactiver (met à jour la base de données pour slocate). Néanmoins, oui, mauvais conseil en général.

— benizi

Oh pardon. J'ai mal lu votre question et j'ai pensé que vous vouliez désactiver TOUS les cronjobs spécifiques au système, pas un seul spécifique.

— jishi