apprentissage utilisation crontab

Gelmou · Le 15/12/2024, à 03:28

Bonjour,

j'ai un petit soucis pour apprendre à utiliser crontab.
C'est un exercice, je veux programmer un affichage (maintenant le temps est passé évidemment) :

crontab -e

je le fais sous nano :

50 2 15 12 0 echo Ah que coucou !

je veux que cela me soit affiché le dimanche 15/12 à 2h50
et j'ai sauvegardé le fichier crontab à 2h48 du même jour.
Puis je vérifie si l'action est bien enregistrée dans le fichier crontab :

gelmou@zenon:~$ crontab -l
# 
# m h  dom mon dow   command
50 2 15 12 0 echo Ah que coucou !

Donc elle est bien enregistrée.

E j'attends devant le terminal que le résultat s'affiche.
Sauf que rien ne se produit.
C'est bien sur le terminal que cela doit s'afficher ?
Si oui, pourquoi il ne se produit rien ?
Une erreur dans l'utilisation de la commande ?

Merci pour votre aide...

Watael · Le 15/12/2024, à 03:37

si tu as un mail local configuré, tu devrais avoir reçu un courrier qui contient le message.
sinon, l'affichage est perdu. tu dois pouvoir le retrouver dans les logs...

tu peux recommencer en ajoutant une redirection vers un fichier :

50 2 15 12 0 echo Ah que coucou ! >/tmp/cron.msg

adapte les horaires bien sûr

jplemoine · Le 15/12/2024, à 04:10

Dans la série des bonnes pratiques :
On ne doit plus utiliser le crontab direct mais un fichier dans /etc/cron.d et indiquer l'utilisateur
format :

# m h dom mon dow user  command

au lieu de

# m h dom mon dow command

Dans ta session, tu as la variable DISPLAY qui indique à l'utilisateur où il doit afficher le message.
En cron, cette variable est vide...
Il faut donc lui indiquer.
Ta ligne devient donc

50 2 15 12 0 DISPLAY=:0.0 echo Ah que coucou !

Ou si tu respectes les bonnes pratiques ci-dessus

50 2 15 12 0 UTIL DISPLAY=:0.0 echo Ah que coucou ! >

à mettre dans un fichier du répertoire /etc/cron.d
UTIL étant ton utilisateur.
Je te conseille aussi de mettre l'entête (à titre de pense-bête) ce qui donne

# m h dom mon dow user  command
50 2 15 12 0 UTIL DISPLAY=:0.0 echo Ah que coucou !

Tu peux envoyer le résultat dans un fichier comme l'a conseillé Watael ci-dessus mais pour être complet, il faut aussi renvoyer les erreurs.

commande > fichier_log 2> fichier_erreur

ou

commande > fichier_log 2>&1

Cette syntaxe permet d'envoyer les erreurs vers la sortie "normale"

sputnick · Le 15/12/2024, à 04:41

jplemoine: DISPLAY=:0.0 ne sert pas pour un echo. C'est uniquement pour les programmes graphiques

kastopidiak · Le 15/12/2024, à 12:48

jplemoine a écrit :

Dans la série des bonnes pratiques :
On ne doit plus utiliser le crontab direct mais un fichier dans /etc/cron.d et indiquer l'utilisateur

Ah. et peut-on voir une documentation officielle qui indique cette « bonne pratique » ?

jplemoine a écrit :

commande > fichier_log 2>&1
Cette syntaxe permet d'envoyer les erreurs vers la sortie "normale"

Non. Il faut être précis cela renvoie la sortie d'erreur (stderr : 2) et la sortie standard (stdout : 1) vers le fichier fichier_log. En fait sortie d'erreur est renvoyé vers la sortie standard, elle m^me renvoyée vers le fichier_log

Gelmou · Le 15/12/2024, à 12:58

Je vous remercie pour vos réponses.
Je suis hélas encore loin d'avoir tout compris.
Ce que j'en retiens donc c'est que c'est pas possible simplement de l'afficher dans le terminal au moment prévu alors ?
Cela ne peut soit qu'être envoyé dans un fichier ou un message si j'ai bien compris...

jplemoine · Le 15/12/2024, à 13:33

sputnick a écrit :

jplemoine: DISPLAY=:0.0 ne sert pas pour un echo. C'est uniquement pour les programmes graphiques

Effectivement, après avoir testé, echo ne fonctionne pas.
Il faut utiliser, par exemple, zenity.
Avec zenity + DISPLAY=:0.0, ça fonctionne.

kastopidiak a écrit :

Non. Il faut être précis cela renvoie la sortie d'erreur (stderr : 2) et la sortie standard (stdout : 1) vers le fichier fichier_log. En fait sortie d'erreur est renvoyé vers la sortie standard, elle m^me renvoyée vers le fichier_log

Oui. J'avais volontairement résumé. Dans mon esprit, c'était des pistes...

kastopidiak a écrit :

Ah. et peut-on voir une documentation officielle qui indique cette « bonne pratique » ?

Non. Je n'ai pas envie de chercher (il y a un truc génial qui s'appelle l'expérience) : Perso, tu fais comme tu veux (les 2 fonctionnent) mais,
en entreprise, quand tu as quelques centaines, voire milliers de serveurs, je te souhaite bon courage si tu veux reprendre les serveurs "à la main".

C'est juste que depuis, de mémoire, 2012, il a été mis en place ce système.

- Le fichier "classique" (notamment les .conf) est réservé au système. Il est susceptible d'être modifié par une mise à jour.
- La personnalisation se fait dans le .d : le système n'y touche pas lors d'une mise à jour.

Libre à toi de l'utiliser ou pas.

L'autre intérêt dans le cas spécifique du cron est que les fichiers "crontab" de tous les utilisateurs (physique ou "de service") sont au même endroit.

kastopidiak · Le 15/12/2024, à 14:59

Non. Je n'ai pas envie de chercher (il y a un truc génial qui s'appelle l'expérience) : Perso, tu fais comme tu veux (les 2 fonctionnent) mais,
en entreprise, quand tu as quelques centaines, voire milliers de serveurs, je te souhaite bon courage si tu veux reprendre les serveurs "à la main".

Donc c'est un choix personnel et non une bonne pratique.
En entreprise on peut s'attendre, et les scripts de maintenance peuvent s'attendre, à trouver les tâches cron des utilisateur sous /var/spool/cron/nom_utilisateur qui est leur emplacement standard.
En entreprise tous les utilisateurs heureusement ne sont pas root (et ne peuvent pas le devenir) et ne peuvent donc pas écrire dans /etc/cron.d. Par contre ils peuvent avoir besoin de créer une tâche planifiée (avec cron ou un timer systemd). C'est une situation assez courante.
Donc ta justification ne tient pas et cela me ferais même douter de l’expérience dont tu te targues.

L'autre intérêt dans le cas spécifique du cron est que les fichiers "crontab" de tous les utilisateurs (physique ou "de service") sont au même endroit.

Si l'on omet le problème majeur que j'ai indiqué, on peut effectivement penser que cela procède d'une meilleure organisation.

Dernière modification par kastopidiak (Le 15/12/2024, à 15:00)

diesel · Le 15/12/2024, à 15:22

kastopidiak a écrit :

Donc c'est un choix personnel et non une bonne pratique.

Non.

La possibilité de mettre des commandes cron dans des fichiers inclus dans ce répertoire a été introduite par les développeurs de cron (comme c'est le cas pour de nombreux utilitaires : ssh-server par exemple). On est bien dans le cadre des bonnes pratiques. Il suffit pour cela de lire le man de crontab dans lequel l'utilisation des fichiers dans le répertoire /etc/cron.d est bien détaillée.

Comme l'a très bien expliqué jplemoine, cela évite de mélanger la config par défaut et la personnalisation sur une machine donnée. Et cela permet aux mainteneurs de faire les mises à jour sans mettre le brin dans les config des utilisateurs.

Après, tu fais comme tu veux sur ta machine : C'est un choix personnel...

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 15/12/2024, à 15:26)

kastopidiak · Le 15/12/2024, à 16:13

La possibilité de mettre des commandes cron dans des fichiers inclus dans ce répertoire a été introduite par les développeurs de cron

Ah bon ? Tu parles de /etc/cron.d ?
Je ne vois rien de tel au niveau du code de Vixie Cron. Par ailleurs la page de man de crontab est tout à fait claire.
Je pense qu'il y a confusion entre les développeurs de cron et les empaqueteurs Debian. Ce sont ces derniers qui forunissent répertoires xxx.d pour surcharger les configuration par défaut de xxx avec celle de l'administrateur système.

Et qu'est-ce que vous ne comprenez pas quand je dit qu'un utilisateur ne pouvant acquérir les droits root et qui a besoin de créer un tâche cron ne peut pas écrire dans /etc/cron.d ?

Et la commande crontab elle est purement décorative ?

man 1 crontab a écrit :

DESCRIPTION
crontab is the program used to install, deinstall or list the tables used to drive the cron(8) daemon in
Vixie Cron. Each user can have their own crontab, and though these are files in /var/spool/cron/crontabs,
they are not intended to be edited directly.

Dernière modification par kastopidiak (Le 15/12/2024, à 16:17)

Watael · Le 15/12/2024, à 16:18

mais, il faut avoir des droits pour écrire sous /etc/cron.d ! ce qu'un utilisateur n'a pas.

dans "mon" man 5 crontab j'ai :

Jobs in /etc/cron.d/
The jobs in cron.d and /etc/crontab are system jobs, which are used usually for more than one user

je veux bien voir votre version de ce man.

O_20_100_O · Le 15/12/2024, à 16:23

Bonjour,

Par contre ils peuvent avoir besoin de créer une tâche planifiée (avec cron ou un timer systemd).

N'est-ce pas le moment d'oublier crontab et de passer à systemd, ses services et ses timers ?

Dernière modification par O_20_100_O (Le 15/12/2024, à 16:24)

kastopidiak · Le 15/12/2024, à 16:26

Ah merci Watael !
Je n'ai pas cela dans man 5 crontab. À vrai dire aucune référence à /etc/cron.d sur ma Debian, ce qui me semble logique vu que ce dossier est le fait des mainteneurs Debian.

Par contre le fichier /etc/crontab foruni par les mainteneurs Debian est documenté :

# /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.

-----------------------------------------------------------
O_20_100_O : ce n'est pas le problème ici et je pense qu'en l'état actuel des choses l'usage de cron reste plus simple (cf. https://wiki.archlinux.org/title/System … %C3%A7ais) pour voir les avantages et inconvénients de chaque méthode)

Dernière modification par kastopidiak (Le 15/12/2024, à 16:30)

jplemoine · Le 15/12/2024, à 17:27

kastopidiak a écrit :

Donc ta justification ne tient pas et cela me ferais même douter de l’expérience dont tu te targues.

Cette réflexion mettra donc un terme au moins momentané à ma collaboration sur ce forum.
Pour les Lyonnais (& assimilés) qui me feraient encore confiance, je continue à être bénévoles à l'ALDIL.
Pour le mois de janvier :
- Jeudi bidouilles le 16/01
- Ecran total (avec normalement une install-Party) le 25/01

diesel · Le 15/12/2024, à 17:32

Si tu es resté sur debian woody, il serait temps d'en changer. aujourd'hui, c'est debian bookworm.

Blague à part, sur debian bookworm, le man 5 crontab n'est pas à jour (tout du moins, sa traduction en français).

Par contre, un man crontab recherché sur internet te parlera bien de /etc/cron.d. Ce n'est donc pas une spécificité de debian.

Amicalement.

Jean-Marie

Watael · Le 15/12/2024, à 17:45

il va me falloir un peu plus que stfw, parce que j'y suis allé, et je n'ai rien trouvé qui confirme tes dires.

j'ai une Ubuntu 24.10 à jour et le man 5 crontab ne fait mention de cron.d que sous "EXAMPLE SYSTEM CRON FILE"

diesel · Le 15/12/2024, à 18:08

De toutes manières, l'utilisation des répertoires /etc/"service".d est devenu quasiment la règle :

jean-marie@jean-marie:/etc$ ls | grep -e "\.d$"
apparmor.d
binfmt.d
cron.d
environment.d
grub.d
init.d
insserv.conf.d
ld.so.conf.d
libibverbs.d
libpaper.d
logrotate.d
modprobe.d
modules-load.d
nfs.conf.d
pam.d
profile.d
rc0.d
rc1.d
rc2.d
rc3.d
rc4.d
rc5.d
rc6.d
rcS.d
request-key.d
rsyslog.d
sane.d
sensors.d
sudoers.d
sysctl.d
tmpfiles.d
update-motd.d
usb_modeswitch.d
jean-marie@jean-marie:/etc$

Je crois que la messe est dite.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 15/12/2024, à 18:09)

Watael · Le 15/12/2024, à 18:27

tu ne prouves rien.
je peux lister mon répertoire personnel, ça ne prouvera pas que la lune est sphérique.

encore une fois :
comment voulez-vous qu'un utilisateur inscrive sa crontab personnelle sous /etc/cron.d/ ?
et pourquoi voulez-vous qu'un utilisateur inscrive sa crontab individuelle sous un répertoire dont les fichiers sont destinés au tâches systèmes ?
Or, me rappeler de prendre mes calmants n'est pas une tâche système, je ne l'inscrirai pas sous /etc/cron.d (de toutes façons, je n'ai pas de droits suffisants pour le faire)
et je serais surpris qu'un admin trouve que c'est une bonne pratique.

Dernière modification par Watael (Le 15/12/2024, à 18:28)

diesel · Le 15/12/2024, à 19:08

Pourquoi veux-tu qu'un utilisateur non admin aille inscrire ses tâches dans /etc/cron.d ?

Ce que j'ai dit, c'est : "cela évite de mélanger la config par défaut et la personnalisation sur une machine donnée. Et cela permet aux mainteneurs de faire les mises à jour sans mettre le brin dans les config des utilisateurs". Par utilisateurs, j'entendais surtout admin dans le cadre d'une utilisation personnelle (de toutes manières, un admin "utilise" la machine. C'est donc quelque part un utilisateur ).

Maintenant, si, pour je ne sais quelle raison, vous ne tenez absolument à ne rien mettre dans le répertoire /etc/cron.d, vous faites bien comme vous voulez.

Et comme jplemoine, ce sera ma dernière contribution sur ce fil.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 15/12/2024, à 19:12)

Watael · Le 15/12/2024, à 19:47

je ne veux pas ne rien y mettre, je veux y mettre ce qui doit y aller : des tâches système.

et pas, comme le dit jplemoine dès qu'un utilisateur veut se faire une crontab, les tâches utilisateurs.
il faut préciser :
cron.d : bonne pratique pour les admin
pour les utilisateurs, crontab -e, c'est très bien; les fichiers seront sous /var/spool/cron.
c'est quand même bien fait linux.

kastopidiak · Le 15/12/2024, à 20:07

Il faut vous calmer
Je vois un intervenant disant des choses inexactes alors qu'il se prétend administrateur système Linux dans sa signature. Je me permet donc de le reprendre pour ne pas que les les lecteurs de ce fil se fourvoient en cédant à l'argument d'autorité du type qui administrerait des centaines de serveurs.
Il ne comprend pas ma réponse, persiste dans son erreur et se vexe. Dont acte.

Là-dessus une autre intervenant (ou le même sous un autre pseudo) vient apporter de la confusion en se mélangeant les pinceaux entre choix des développeurs d'un logiciel avec ceux des mainteneurs de la distribution. Puis essaie de noyer le poisson en faisant comme s'il n'avait pas compris ce que j'écrivais. Lui aussi semble avoir la science infuse, persiste et se vexe. Dont acte.

C'est bien dommage parce que l'on a tout à perdre avec cette attitude et au contraire tout à gagner lorsque l'on veut bien reconnaître que l'on ne connaît pas tout, que l'on est faillible et que l'on a pas forcément bien lu ou bien compris les propos d'autrui.

P.S. : et pour que les choses soit plus claire dans l'esprit de diesel. C'est le paquet cron-daemon-common qui fournit la configuration par défaut pour cron et il ne fournit que des éléments de configuration décidés par les mainteneurs Debian. Pour les pages de man soi-disant pas à jour je l'invite à consulter celle du code source de Vixie Cron que j'ai déjà donné en lien. Il pourra aussi réfléchir sur la manière dont les mainteneurs debian apportent des correctifs aux logiciels et à leurs page de manuel. Seul la page de man fournie avec le paquet logiciel peut faire foi. Ce que l'on trouve sur le Web peut être issu d'un toute autre distribution.

P.S. 2 : pour watael, nous sommes d'accord sudo crontab -e, ce n'est pas très judicieux

Dernière modification par kastopidiak (Le 15/12/2024, à 20:09)

geole · Le 15/12/2024, à 21:40

Bonsoir.
En fabricant un service utilisateur, le débat devient caduc.

O_20_100_O · Le 16/12/2024, à 08:38

Gelmou a écrit :

j'ai un petit soucis pour apprendre à utiliser crontab.
C'est un exercice, je veux programmer un affichage

Est-ce que l'affichage en question est juste un moyen comme un autre de vérifier que l"action planifiée se déclenche bien ?
Ou alors veux-tu vraiment un affichage dans le terminal ?

D'autre part, comme vu plus haut, il existe d'autres moyens pour programmer des événements.
https://wiki.archlinux.org/title/System … %C3%A7ais)
https://doc.ubuntu-fr.org/creer_un_service_avec_systemd

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 15/12/2024, à 03:28

apprentissage utilisation crontab

#2 Le 15/12/2024, à 03:37

Re : apprentissage utilisation crontab

#3 Le 15/12/2024, à 04:10

Re : apprentissage utilisation crontab

#4 Le 15/12/2024, à 04:41

Re : apprentissage utilisation crontab

#5 Le 15/12/2024, à 12:48

Re : apprentissage utilisation crontab

#6 Le 15/12/2024, à 12:58

Re : apprentissage utilisation crontab

#7 Le 15/12/2024, à 13:33

Re : apprentissage utilisation crontab

#8 Le 15/12/2024, à 14:59

Re : apprentissage utilisation crontab

#9 Le 15/12/2024, à 15:22

Re : apprentissage utilisation crontab

#10 Le 15/12/2024, à 16:13

Re : apprentissage utilisation crontab

#11 Le 15/12/2024, à 16:18

Re : apprentissage utilisation crontab

#12 Le 15/12/2024, à 16:23

Re : apprentissage utilisation crontab

#13 Le 15/12/2024, à 16:26

Re : apprentissage utilisation crontab

#14 Le 15/12/2024, à 17:27

Re : apprentissage utilisation crontab

#15 Le 15/12/2024, à 17:32

Re : apprentissage utilisation crontab

#16 Le 15/12/2024, à 17:45

Re : apprentissage utilisation crontab

#17 Le 15/12/2024, à 18:08

Re : apprentissage utilisation crontab

#18 Le 15/12/2024, à 18:27

Re : apprentissage utilisation crontab

#19 Le 15/12/2024, à 19:08

Re : apprentissage utilisation crontab

#20 Le 15/12/2024, à 19:47

Re : apprentissage utilisation crontab

#21 Le 15/12/2024, à 20:07

Re : apprentissage utilisation crontab

#22 Le 15/12/2024, à 21:40

Re : apprentissage utilisation crontab

#23 Le 16/12/2024, à 08:38

Re : apprentissage utilisation crontab

Pied de page des forums