Задания крона обнаруживаются в Планировщике GNOME, но не выполняются

Кажется, что Empathy может понадобиться патч, чтобы делать это внутри. Но вы должны быть способны совать Empathy, чтобы сделать правильную вещь, отключившись от вашей сети и снова подключиться.

У меня, похоже, были ошибки с Empathy, которые отказывались подключаться к сети в разное время.

Но это займет код, и если вы этого захотите, необходимо сделать отчет об ошибке.

3
задан 2 July 2015 в 21:16

5 ответов

Судя по вашим записям в журнале, ваши задания недавно не запускались.

Вам также следует проверить архивированные журналы cron, поскольку они могли перевернуться с момента их последнего запуска.

Для дальнейшей отладки я бы добавил эту работу, используя crontab -e

*/5 * * * * echo hello

и посмотрев, отправляет ли она вам почту и появляется ли она в файле журнала.

обновление: Если оно появляется в файле журнала, но не отправляет вам почту, вам может потребоваться либо установить почтовый агент, чтобы просмотреть выходные данные заданий резервного копирования, либо запустить их с перенаправленным выводом файл журнала. Например, вы можете использовать crontab -e, чтобы изменить одну строку на

0 15 * * * nice -n 19 /usr/bin/backintime --backup-job >> ~/log/backup.log 2>&1

, вам нужно будет создать каталог ~/log.

0
ответ дан 2 July 2015 в 21:16

Gnome Scheduler - просто симпатичный интерфейс для at и crontab. И в Ubuntu по умолчанию cron в основном запускает anacron, который отвечает за выполнение периодических задач на машинах, которые могут не включаться, когда задача должна запускаться.

Что нужно проверить:

  • cron запущен? ps -C cron
  • настроен ли cron? cat /etc/crontab
  • cron вызывает анакрон из / etc / crontab?
  • установлен анакрон? ls /usr/sbin/anacron
  • cron или anacron регистрируют какие-либо сообщения вообще? grep CRON /var/log/syslog

На последнем шаге logrotate, возможно, заархивировал старые системные журналы, поэтому если grep не дает результата, попробуйте

(cat /var/log/syslog.[0-9] ; zcat /var/log/syslog.*.gz) | grep CRON

Я предполагаю, что gnome-scheduler устанавливает создавать задания с неправильными разрешениями (вероятно, вы, а не суперпользователь), и поэтому жалобы будут появляться в системных журналах.

ответ на обновление

Учитывая приглашение оболочки в вашем примере crontab -l, вы почти наверняка перечислили crontab для каждого пользователя bakhtiyor, который может не иметь разрешений для выполнения ваших (несколько непрозрачных) заданий.

Записи в системном журнале покажут, выполняются ли задания вообще, и если да, если задания жалуются.

0
ответ дан 2 July 2015 в 21:16

Это решение сработало для меня: https://answers.launchpad.net/backintime/+question/90513

Моя конфигурация работы была сохранена под моим пользователем, а не под root, потому что использовал sudo backintime-gnome, а не gksu backintime-gnome.

sudo не изменит среду HOME, что вызывает проблемы:

$ sudo env | grep ^HOME
HOME=/home/user
$ gksu env | grep ^HOME
HOME=/root
0
ответ дан 2 July 2015 в 21:16

У меня возникла та же проблема, и я решил ее, добавив свое имя пользователя в группу crontab.

  1. Редактировать /etc/group
  2. Найдите строку, содержащую crontab (должно быть только 1 строку)
  3. Добавьте свое имя пользователя в конце (если другие пользователи находятся на линии разделяйте запятой)
  4. перезагрузка
0
ответ дан 2 July 2015 в 21:16

У меня была похожая проблема, которая привела меня в замешательство. Предполагая, что cron, crontab и anacron исправны, ключевым симптомом является то, что задача запускается правильно, если вызывается с помощью кнопки «запустить сейчас» в gnome-schedule, но не запускается, как запланировано, если ее оставить в покое.

Это оказывается главным образом проблемой графического окружения. Я рекомендую создать оболочку для сценария задачи, например, "task-wrapper":

#!/bin/sh
gnome-terminal -x /home/username/task

Убедитесь, что файл task-wrapper является исполняемым, и создайте задачу в gnome-schedule как приложение X. В качестве альтернативы, напишите это так:

#!/bin/sh
export DISPLAY=:0
gnome-terminal -x /home/username/task

Сценарий / home / username / task теперь будет запускаться в окне консоли, которое закрывается после завершения. Мои сценарии обычно требуют аутентификации sudo, поэтому я запускаю сценарий «task» следующим образом:

#!/bin/sh
set -e
MESSAGE="The task script wants to ..."
gksudo --message "$MESSAGE" cd /whatever

Команда cd является неточной, MESSAGE объясняет, для чего сценарий запрашивает авторизацию, и «set -e» гарантирует, что скрипт прерывается, если пользователь нажимает кнопку «Отмена». В оставшейся части сценария могут использоваться простые вызовы sudo, которые будут успешными, если между командами не пройдет много времени.

В Ubuntu 12.04 членство в crontab, по-видимому, не требуется.

0
ответ дан 2 July 2015 в 21:16

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

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