crontab-e не открывает crontab для этого пользователя

Я настроил несколько использований заданий crontab несколько месяцев назад и они работали хорошо вплоть до несколько дней назад, я заметил, что тот не работал. Я просто попытался проверить crontab файл с помощью пользователя, который создал задания, с помощью crontab -e, и никакой файл не открывается. Терминал быстро мелькает экран tosome и затем обратно на экран, где я ввел команду. Это идет и возвращается слишком быстро, чтобы я видел то, что там.

Я имею (как sudo) проверенный под /var/spool/cron/crontab/ и посмотрите, что существует файл для упомянутого пользователя, который содержит основное:

> 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 $)

Я замечаю, что дата установки в значительной степени точно где мои остановленные задания крона! Возможно, системе был нужен перезапуск по некоторым причинам...

Я перезапустил машину и снова попробовал: crontab -e, на этот раз я получил следующую ошибку, прибывающую из Emacs (редактор по умолчанию, я верю):

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]

Таким образом, я изменил редактора по умолчанию на 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

... и попробованный еще раз:

user@user:~$ crontab -e

Это просто дало ту же проблему, как первоначально описано - это вскоре, казалось, открывалось, файл затем закрывают его снова.

Там другой путь состоит в том, чтобы отладить и (надо надеяться) возвратить исходный crontab файл? С работы ушли комплекс для установки (см. примечание № 2 ниже), :-/

Я пытался найти выполнение crontab задачами с помощью этого ответа, таким образом, крон работает, но что относительно моих crontab задач?

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

Другие примечания:

  • anacron установлен
  • сами задания крона определяются в crontab файле, не с помощью внешних сценариев
  • один cronjob использовал виртуальный ENV, который действительно все еще существует и работает, и я могу выполнить задание вручную

Обновления:

Вывод от некоторых дальнейших проверок (главным образом требуемый @steeldriver)

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

Это setuid s там? Я сравнил его с ping, потому что я считал, что должен иметь некоторые поднятые полномочия:

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

Выполнение crontab как sudo:

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

Попытка желаемой команды как sudo, использование установки пользователя:

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

Проверка, как ожидалось ли полномочия для всей шпульки:

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
2
задан 1 April 2018 в 15:35

1 ответ

Только, чтобы отправить результат и возможно помочь кому-то, кто видит то же самое - это - сводка комментариев ниже моего исходного вопроса

Используя crontab -e был запуск проблемы - это ничего не сделало.

Оказывается, что установка Emacs была причиной (но я предполагаю, что любой другой редактор мог так или иначе вызвать эту проблему).

Следование совету @steeldriver попытки EDITOR=/bin/nano crontab -e (пытающийся вынудить crontab использовать нано не помог.

Я записал скринкаст и остановился на кадре, где файл быстро открывается - это был экран-заставка Emacs.

Были настройки в ~/.profile, который заставил демона Emacs угонять вызовы редактору. После удаления тех, которые устанавливают и перезапуска, crontab -e поскольку пользователь работал.

Настройки, казалось, были неправильно вставляемой копией версией этого (найденный на Wiki 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

[Я не помню, где фактическая ошибка была]

Исходный crontab файл был потерян. Я все еще не понимаю, как это произошло

0
ответ дан 2 December 2019 в 07:52

Другие вопросы по тегам:

Похожие вопросы: