web-dev-qa-db-fra.com

crontab -e n'ouvre pas la crontab pour cet utilisateur

J'avais créé quelques emplois en utilisant crontab il y a quelques mois et ils travaillaient bien jusqu'à il y a quelques jours. J'ai remarqué qu'un poste ne s'était pas présenté. J'ai juste essayé de vérifier le fichier crontab en utilisant l'utilisateur qui a créé les travaux, en utilisant crontab -e, et aucun fichier ne s'ouvre. Le terminal bascule rapidement sur certains écrans, puis revient à l'écran où j'avais saisi la commande. Ça va et ça revient trop vite pour que je voie ce qui est là.

J'ai (comme Sudo) vérifié sous /var/spool/cron/crontab/ et vois qu'il existe un fichier pour l'utilisateur mentionné, qui contient la base:

> DO NOT EDIT THIS FILE - edit the master and reinstall.
> (- installed on Wed Mar 21 00:12:22 2018)
> (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

Je remarque que cette date n'est pas exactement la même que celle où mes tâches cron se sont arrêtées! Peut-être que le système avait besoin d'un redémarrage pour une raison quelconque ...

J'ai redémarré la machine et essayé à nouveau: crontab -e, cette fois, le message d'erreur suivant provient de Emacs (l'éditeur par défaut, je crois):

emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".

Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715

.... [truncated]

J'ai donc changé l'éditeur par défaut en nano:

user@user:~$ select-editor 

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/code
  4. /usr/bin/emacs24
  5. /usr/bin/vim.tiny

Choose 1-5 [2]: 2

... et réessayé:

user@user:~$ crontab -e

Cela a juste donné le même problème que décrit initialement - il a semblé très bientôt ouvrir un fichier puis le refermer.

Existe-t-il un autre moyen de déboguer et (espérons-le) de récupérer le fichier crontab d'origine? Les travaux ont été compliqués à configurer (voir note 2 ci-dessous): - /

J'ai essayé de trouver des tâches crontab en cours d'exécution en utilisant cette réponse , donc cron est en cours d'exécution, mais qu'en est-il de mes tâches crontab?

user@user:~$  ps -o pid,sess,cmd afx | egrep "( |/)cron( -f)?$"
1077  1077 /usr/sbin/cron -f

Autres notes:

  • anacron est installé
  • les travaux cron eux-mêmes sont définis dans le fichier crontab, et non via des scripts externes
  • un cronjob a utilisé un env virtuel, qui existe toujours et fonctionne et je peux exécuter le travail manuellement

Mises à jour:

Le résultat de quelques vérifications supplémentaires (principalement demandé par @steeldriver)

user@user:~$ ls -l $(which crontab)
-rwxr-sr-x 1 root crontab 36080 Apr  5  2016 /usr/bin/crontab

Est-ce que la setuid s est là? Je l'ai comparé à ping, car j'ai lu que cela devrait avoir une sorte d'autorisations élevées:

user@user:~$ ls -l $(which ping)
-rwsr-xr-x 1 root root 44168 Mai  7  2014 /bin/ping

Lancer crontab comme Sudo:

user@user:~$ Sudo crontab -e
[Sudo] password for user: 
no crontab for root - using an empty one
No modification made

Essayer la commande souhaitée en tant que Sudo, en utilisant la configuration de l'utilisateur:

user@user:~$ Sudo -H -u user bash -c 'crontab -e'
No modification made

Vérification si les autorisations pour le spool entier sont comme prévu:

user@user:~$ ls -ld /tmp
drwxrwxrwt 16 root root 36864 Apr  1 14:22 /tmp
user@user:~$ Sudo namei -l /var/spool/cron/crontabs/$USER
f: /var/spool/cron/crontabs/user
drwxr-xr-x root    root    /
drwxr-xr-x root    root    var
drwxr-xr-x root    root    spool
drwxr-xr-x root    root    cron
drwx-wx--T root    crontab crontabs
-rw------- user    crontab user
command-linecron
2
n1k31t4

Juste pour poster le résultat et peut-être aider quelqu'un qui voit la même chose - ceci est un résumé des commentaires ci-dessous ma question initiale

Utiliser crontab -e était le début du problème - cela n’a rien fait.

Il s’avère que la configuration d’Emacs en est la cause (mais je suppose que tout autre éditeur pourrait causer ce problème).

Suivre le conseil de @steeldriver d'essayer EDITOR=/bin/nano crontab -e (essayer de forcer crontab à utiliser nano n'a pas aidé.

J'ai enregistré une projection d'écran et je me suis arrêté sur le cadre où un fichier s'ouvre rapidement: il s'agissait de l'écran de démarrage d'Emacs.

Il y avait des paramètres dans ~/.profile, ce qui a amené le démon Emacs à détourner des appels à un éditeur. Après avoir supprimé ces paramètres et redémarré, crontab -e pendant que l'utilisateur travaillait.

Les paramètres semblaient être une version copiée-collée de manière incorrecte (trouvée sur le wiki d'Emacs):

export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t"                  # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs"         # $VISUAL opens in GUI with non-daemon as alternate

[Je ne me souviens pas où l'erreur a été réelle]

Le fichier crontab d'origine a été perdu. Je ne comprends toujours pas comment c'est arrivé

0
n1k31t4