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

Я настроил Back In Time и MySQL Administrator для резервного копирования каждый день в 15:00. Чтобы убедиться, что я установил Gnome Scheduler, чтобы увидеть, зарегистрированы ли эти два приложения там. Они зарегистрированы в планировщике GNOME, но не выполняют операции резервного копирования.

Вот скриншот Gnome Scheduler.

альтернативный текстКак я могу решить эту проблему?

ОБНОВИТЬ

Выход из crontab -l команда следующая:

bakhtiyor@ubuntu-vm:~$ crontab -l
0 15 * * * /usr/bin/mabackup -d /home/bakhtiyor/backup/MySQL -x my-backup profile # JOB_ID_3
0 15 * * * nice -n 19 /usr/bin/backintime --backup-job # JOB_ID_2

ОБНОВЛЕНИЕ 2

Выход из grep CRON /var/log/syslog команда следующая:

Nov 30 11:39:01 ubuntu-vm CRON[7663]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Nov 30 11:39:02 ubuntu-vm CRON[7661]: (CRON) info (No MTA installed, discarding output)
Источник

5 ответов

Решение

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 Например, вы почти наверняка перечислили bakhtiyor для каждого пользователя crontab, который может не иметь разрешений для запуска ваших (несколько непрозрачных) заданий.

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

Источник

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

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

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

*/5 * * * * echo hello

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

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

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

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

Источник

Это решение работало для меня: 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
Источник

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

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

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

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

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

Убедитесь, что файл программы-оболочки является исполняемым, и создайте задачу в 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 является неточной, СООБЩЕНИЕ объясняет, для чего скрипт запрашивает авторизацию, а set -e гарантирует, что скрипт прерывается, если пользователь нажимает "Отмена". Оставшаяся часть сценария может использовать простые вызовы sudo, которые будут успешными, если между командами не пройдет много времени.

В Ubuntu 12.04 членство в группах crontab не требуется.

Источник
Другие вопросы по тегам