Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 11-02-2020 17:44:49

alpha.centauri
Membre
Lieu : Toulouse
Distrib. : stretch
(G)UI : XFCE
Inscription : 14-11-2019

(résolu)embrouille crontab

hello,

j'ai un truc bizarre : en regardant mon syslog.conf, je vois ça :

Feb 11 06:25:01 debian CRON[20522]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))

je ne sais plus d'où sort cet anacron, en tout cas, il n'est plus dans le système; du coup je veux le virer et c'est là que ça devient bizarre...

j'ai bien un fichier /etc/crontab, appartenant à root et dans lequel je retrouve
25 6    * * *    root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

mais, quand je fais un crontab -e sous root, ça me dit qu'il n'y a pas de crontab pour l'utilisateur root...

du coup, je m'interroge...

Dernière modification par alpha.centauri (18-02-2020 22:39:36)

Hors ligne

#2 17-02-2020 19:52:12

Renart_frambivore
Membre
Distrib. : Debian GNU/Linux buster
Noyau : 4.19.0-8-amd64
(G)UI : XFCE4
Inscription : 07-09-2018

Re : (résolu)embrouille crontab

Salut,
tu peux modifier ton crontab avec nano.
J'ai toujours fais comme ça, et j' n'ai jamais eu de soucis.

nano /etc/crontab


Maître Renart, par l'odeur alléché, Lui tint à peu près ce langage : "sudo apt-get update && sudo apt-get upgrade && sudo apt-get autoremove && sudo reboot"

En ligne

#3 18-02-2020 08:14:53

alpha.centauri
Membre
Lieu : Toulouse
Distrib. : stretch
(G)UI : XFCE
Inscription : 14-11-2019

Re : (résolu)embrouille crontab

oui, c'est bien ce que j'ai fait smile

mais j'aimerais quand même bien comprendre pourquoi crontab -e, ou -l, me dit qu'il n'y a pas de crontab pour root alors qu'il n'y a pas de pb avec un autre utilisateur...

Hors ligne

#4 18-02-2020 13:53:19

Renart_frambivore
Membre
Distrib. : Debian GNU/Linux buster
Noyau : 4.19.0-8-amd64
(G)UI : XFCE4
Inscription : 07-09-2018

Re : (résolu)embrouille crontab

alpha.centauri a écrit :

mais j'aimerais quand même bien comprendre pourquoi crontab -e, ou -l, me dit qu'il n'y a pas de crontab pour root alors qu'il n'y a pas de pb avec un autre utilisateur...


Dans mon cas, les deux commandes fonctionnent.
Par contre, mon fichier /etc/crontab n'est pas récupéré : on m'affiche une page avec une notice en commentaire.
tu peux toujours faire un tour dans le manuel :

man crontab


CRONTAB(1)                                                        General Commands Manual                                                       CRONTAB(1)

NAME
       crontab - maintain crontab files for individual users (Vixie Cron)

SYNOPSIS
       crontab [ -u user ] file
       crontab [ -u user ] [ -i ] { -e | -l | -r }

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.

       If the /etc/cron.allow file exists, then you must be listed (one user per line) therein in order to  be  allowed  to  use  this  command.   If  the
       /etc/cron.allow  file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use
       this command.

       If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use  this  com‐
       mand, or all users will be able to use this command.

       If  both  files  exist  then  /etc/cron.allow  takes precedence.  Which means that /etc/cron.deny is not considered and your user must be listed in
       /etc/cron.allow in order to be able to use the crontab.

       Regardless of the existence of any of these files, the root administrative user is always allowed to setup a crontab.  For standard Debian systems,
       all users may use this command.

       If the -u option is given, it specifies the name of the user whose crontab is to be used (when listing) or modified (when editing).  If this option
       is not given, crontab examines "your" crontab, i.e., the crontab of the person executing the command.  Note that su(8) can confuse crontab and that
       if you are running inside of su(8) you should always use the -u option for safety's sake.

       The first form of this command is used to install a new crontab from some named file or standard input if the pseudo-filename ``-'' is given.

       The -l option causes the current crontab to be displayed on standard output.  See the note under DEBIAN SPECIFIC below.

       The -r option causes the current crontab to be removed.

       The  -e  option  is used to edit the current crontab using the editor specified by the VISUAL or EDITOR environment variables.  After you exit from
       the editor, the modified crontab will be installed automatically.  If neither of the environment variables is  defined,  then  the  default  editor
       /usr/bin/editor is used.

       The -i option modifies the -r option to prompt the user for a 'y/Y' response before actually removing the crontab.

DEBIAN SPECIFIC
       The  "out-of-the-box"  behaviour  for crontab -l is to display the three line "DO NOT EDIT THIS FILE" header that is placed at the beginning of the
       crontab when it is installed.  The problem is that it makes the sequence

       crontab -l | crontab -

       non-idempotent — you keep adding copies of the header.  This causes pain to scripts that use sed to edit a crontab.  Therefore, the default  behav‐
       iour  of  the  -l  option  has  been  changed to not output such header.  You may obtain the original behaviour by setting the environment variable
       CRONTAB_NOHEADER to 'N', which will cause the crontab -l command to emit the extraneous header.

SEE ALSO
       crontab(5), cron(8)

FILES
       /etc/cron.allow
       /etc/cron.deny
       /var/spool/cron/crontabs

       The files /etc/cron.allow and /etc/cron.deny if, they exist, must be either world-readable, or readable by group ``crontab''. If they are not, then
       cron will deny access to all users until the permissions are fixed.

       There  is one file for each user's crontab under the /var/spool/cron/crontabs directory.  Users are not allowed to edit the files under that direc‐
       tory directly to ensure that only users allowed by the system to run periodic tasks can add them, and only syntactically correct crontabs  will  be
       written there.  This is enforced by having the directory writable only by the crontab group and configuring crontab command with the setgid bid set
       for that specific group.

STANDARDS
       The crontab command conforms to IEEE Std1003.2-1992 (``POSIX'').  This new command syntax differs from previous versions of Vixie Cron, as well  as
       from the classic SVR3 syntax.

DIAGNOSTICS
       A fairly informative usage message appears if you run it with a bad command line.

       cron  requires  that each entry in a crontab end in a newline character.  If the last entry in a crontab is missing the newline, cron will consider
       the crontab (at least partially) broken and refuse to install it.

       The files under /var/spool/cron/crontabs are named based on the user's account name.  Crontab jobs will not be run for users  whose  accounts  have
       been renamed either due to changes in the local system or because they are managed through a central user database (external to the system, for ex‐
       ample an LDAP directory).

AUTHOR
       Paul Vixie <paul@vix.com> is the author of cron and original creator of this manual page.  This page has also been modified  for  Debian  by  Steve
       Greenland, Javier Fernandez-Sanguino and Christian Kastner.

4th Berkeley Distribution                                              19 April 2010                                                            CRONTAB(1)


Maître Renart, par l'odeur alléché, Lui tint à peu près ce langage : "sudo apt-get update && sudo apt-get upgrade && sudo apt-get autoremove && sudo reboot"

En ligne

#5 18-02-2020 19:39:38

yap22
Membre
Lieu : Bro Dreger (Breizh)
Distrib. : Debian stable
Noyau : Linux 4.19.0-8-amd64
(G)UI : Xfce
Inscription : 29-02-2016

Re : (résolu)embrouille crontab

Bonjour,

La commande

crontab -e

va générer le fichier /var/spool/cron/crontabs/$USER.

Lorsque l'on utilise cette même commande avec le compte root alors son comportement est le même qu'avec un utilisateur standard.

Les fichiers /etc/cron* sont utilisés pour les tâches répétitives du système.
Exemples :
- ocsinventory installe un fichier de commande dans /etc/cron.daily ou /etc/cron.hourly suivant la distribution utilisée
- pour lancer les sauvegardes des VM, proxmox rajoute un fichier vzdumpcron dans /etc/cron.d
- logrotate est activé depuis /etc/cron.daily

Hors ligne

#6 18-02-2020 22:37:16

alpha.centauri
Membre
Lieu : Toulouse
Distrib. : stretch
(G)UI : XFCE
Inscription : 14-11-2019

Re : (résolu)embrouille crontab

OK, si je comprends bien, le fichier /etc/crontab, bien qu'appartenant à root, n'est pas le "crontab" de root ; donc tout s'explique... smile

merci...

Hors ligne

Pied de page des forums