[Cron]Remplacement par Cronie

[Ypnose]

Bonsoir,
En plus de la surprise net-tools / inetutils ce matin (sans annonce), il semblerait que cron soit remplacé par cronie. J'ai un peu discuté avec FoolEcho, à ce sujet.
Je peux donc garder mon 'ancien' paquet cron de base?
Et puis j'y pense aussi, je n'ai jamais ajouté de tâche planifié, est-il donc utile de toujours garder le daemon dans le rc.conf (même si je pense qu'il y a des tâches planifiés par le système lui-même)?

[benjarobin]

A ce que j'ai pu lire cronie est conseillé par rapport à crond. Sinon il est fortement déconseillé de désactiver cron, en effet il y a par exemple la tache qui gère la taille de tes log pour éviter que ceux-ci explosent. Puis tu en as une autre qui s'occupe de l'indexation de tes fichiers (updatedb pour la commande locate)

[chipster]

tu peux me faire un crontab -e stp ?
Perso c'est totalement vierge pour ma part

[oktoberfest]

Si ton pc est allumé 24h/24, cron a son utilité.
Si c'est un pc allumé occasionnellement (éteint la nuit par exemple), cron est beaucoup moins utile car la majorité des tâches systèmes planifiés (la rotation des logs par exemple) est prévue la nuit.

[tuxce]

Bonsoir,
En plus de la surprise net-tools / inetutils ce matin (sans annonce)

inetutils faisant partie de base, il ne devaient pas y avoir de surprise.

il semblerait que cron soit remplacé par cronie.

cronie fait maintenant partie du groupe base (mais ce changement date de bien longtemps), mais dcron n'est pas supprimé, du coup, il n'y a aucune incidence sur une ancienne installation.

Et puis j'y pense aussi, je n'ai jamais ajouté de tâche planifié, est-il donc utile de toujours garder le daemon dans le rc.conf (même si je pense qu'il y a des tâches planifiés par le système lui-même)?

Code : Tout sélectionner

ls /etc/cron.*

te donnera la réponse; en plus de ce qu'un utilisateur aurait éventuellement rajouté:

Code : Tout sélectionner

ls /var/spool/cron

Si c'est un pc allumé occasionnellement (éteint la nuit par exemple), cron est beaucoup moins utile car la majorité des tâches systèmes planifiés (la rotation des logs par exemple) est prévue la nuit.

dcron depuis la version 4 et cronie intègrent anacron sinon il y a le paquet anacron pour lancer les tâches dont le temps d'activation a été dépassé.

[FoolEcho]

@chipster: À l'instar de la création d'une nouvelle table pour un utilisateur, on part effectivement de zéro... Dans le fonctionnement, ça ne change rien mais c'est dommage par rapport à la version de dcron qui donnnait le standard de formatage.

Il faut remettre en place la table pour root (un pacsave a été fait normalement). Et certaines commandes pour crontab ont changé (voir le man). Je n'ai pas vérifié dans le détail (notamment l'apport d'anacron) mais tout semble fonctionner ( les @hourly, etc. et /etc/cron.*/ sont bien pris en compte -- bon, maintenant j'ai pas des milliers de tâches... ). Anecdotiquement, le seul bémol que j'ai vu dans le log de cron et qu'il cherche un /etc/crontab (mais c'était déjà le cas avec dcron).
Lien vers le hors-sujet précédent: http://forums.archlinux.fr/post79701.html#p79701 et surtout l'annonce officielle confidentielle: https://bbs.archlinux.org/viewtopic.php?id=120100 .

Je peux donc garder mon 'ancien' paquet cron de base?

Oui. Mais la principale raison au remplacement de dcron et qu'en cas de bug, les développeurs actuels ne pourront réagir rapidemment (du coup, le paquet a souffert d'être souvent cassé ces derniers temps, d'où son retrait du groupe base).

inetutils faisant partie de base, il ne devaient pas y avoir de surprise.

Pas vu passer non plus... Et si je n'avais pas eu à faire avec cron récemment, je ne l'aurai pas vu non plus.

[jaco]

inetutils faisant partie de base, il ne devaient pas y avoir de surprise.

Sauf que ceux qui ont déjà Arch d'installé et qui se contentent de le mettre à jour par pacman, rien n'a été annoncé...

[tuxce]

Ok j'avais pas saisi pour inetutils , je pensais qu'il était dans "base" avec net-tools et que du coup, le fait que le bin "hostname" ait été déplacé ne devait pas induire d'erreurs, surtout que wicd avait une erreur due plutôt à la différence de sortie de la commande ifconfig ...

[Ypnose]

tuxce: aucune infos comme a dit jaco. J'ai fait la découverte grâce au forum, d'ailleurs.

Merci les gars pour les précisions. Je me doutais qu'il ne fallait pas enlever cron mais maintenant je sais vraiment pourquoi.

Super forum!

[FoolEcho]

Ok j'avais pas saisi pour inetutils

D'où ma demande vis-à-vis du wiki sur startx avec hostname (hostname revient dans base par l'intermédiaire de inetutils, donc par conséquent on ne devrait pas l'indiquer... sauf qu'on peut totalement rater ce paquet comme l'atteste les récents messages sur le forum... je chipote un peu, mais peut-être le préciser ? ).

[FoolEcho]

Sinon, parce que je pense que ça peut en rassurer certains (dont moi en fait : j'ai pu regarder et tester un peu plus en détail), en ce qui concerne le pourquoi de la table vide avec crontab -e: les différentes tâches en rapport avec /etc/crond.hourly, daily, weekly, monthly n'ont plus besoin de figurer dans la crontab de root.
En gros: cron a déjà une tâche qui s'occupe de lancer celles de /etc/crond.hourly (toutes les heures + 1 minute pétante), dont une concernant anacron (autre nouveauté par rapport à cronie) qui s'occupe de lancer les tâches /etc/crond.d/daily/weekly/monthly (donc la rotation des différents logs est assurée).

Par conséquent, aucun problème avec la table vide obtenue par crontab -e et un éventuel passage à cronie.
Il faut simplement ajouter vos propres tâches minutées supplémentaires récupéré depuis la table précédente, un pacsave normalement dans /var/spool/cron (téléchargement de mises à jours à telle heure, etc..).

Y aura plus qu'à faire glisser le fichier d'exemple du wiki sur un petit couplet sur dcron et hop... :sifflote: (j'essaierai de voir ça demain, sauf si quelqu'un est plus rapide ).