Я настроил Назад во времени и MySQL Administrator для создания резервного копирования каждый день в 15:00. Чтобы быть уверенным, что я установил Планировщик Gnome, чтобы видеть, регистрируются ли эти два приложения там. Они регистрируются в планировщике гнома, но они не работают, создают резервную копию операции.
Вот снимок экрана Планировщика Gnome.
Как я могу решить эту проблему?
ОБНОВЛЕНИЕ
Вывод 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)
Судя по вашим записям в журнале, ваши задания недавно не запускались.
Вам также следует проверить архивированные журналы cron, поскольку они могли перевернуться с момента их последнего запуска.
Для дальнейшей отладки я бы добавил эту работу, используя crontab -e
*/5 * * * * echo hello
и посмотрев, отправляет ли она вам почту и появляется ли она в файле журнала.
обновление: Если оно появляется в файле журнала, но не отправляет вам почту, вам может потребоваться либо установить почтовый агент, чтобы просмотреть выходные данные заданий резервного копирования, либо запустить их с перенаправленным выводом файл журнала. Например, вы можете использовать crontab -e
, чтобы изменить одну строку на
0 15 * * * nice -n 19 /usr/bin/backintime --backup-job >> ~/log/backup.log 2>&1
, вам нужно будет создать каталог ~/log
.
Gnome Scheduler - просто симпатичный интерфейс для at
и crontab
. И в Ubuntu по умолчанию cron
в основном запускает anacron
, который отвечает за выполнение периодических задач на машинах, которые могут не включаться, когда задача должна запускаться.
Что нужно проверить:
ps -C cron
cat /etc/crontab
ls /usr/sbin/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, который может не иметь разрешений для выполнения ваших (несколько непрозрачных) заданий.
Записи в системном журнале покажут, выполняются ли задания вообще, и если да, если задания жалуются.
Это решение сработало для меня: 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.
/etc/group
У меня была похожая проблема, которая привела меня в замешательство. Предполагая, что 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, по-видимому, не требуется.