Согласно этому отчету об ошибке, tasksel ведет себя плохо при удалении пакетов. Кажется, что он удаляет многие пакеты, которые он не должен, что может оставить машину в противоречивом состоянии.
Чтобы удалить что-то, что вы установили с tasksel, вы должны упомянуть пакеты специально. Например:
sudo aptitude remove apache2 apache2.2-common php5-common mysql-common
Теория состоит в том, что удаление этих пакетов приведет к удалению других частей каждой системы. Тем не менее, ручной поиск через Synaptic все равно будет полезен.
этот отчет об ошибке дает гораздо более подробный список того, что нужно удалить, если вы пытаетесь удалить LAMP stack.
Чтобы восстановить из-за чрезмерно усердной абсорбции tasksel, вам необходимо переустановить уязвимые пакеты. В некоторых случаях установка ubuntu-desktop сделает трюк:
sudo aptitude install ubuntu-desktop
Чтобы быть более основательным, откройте Центр программного обеспечения Ubuntu и просмотрите историю удаления (см. Снимок экрана), чтобы найти пакеты, которые были удалено одновременно с тем, что вы выполнили tasksel remove. Затем вы можете переустановить эти пакеты.
В зависимости от ваших записей в журнале, похоже, что ваши задания не выполнялись в последнее время.
Вы также должны проверить архивные журналы cron, потому что они, возможно, перевернулись с момента последнего запуска.
Чтобы отладить это, я добавлю это задание, используя crontab -e
*/5 * * * * echo hello
и посмотрю, отправляет ли он вам почту и отображается ли она в файле журнала.
[d4 ] update: если он появляется в файле журнала, но не отправляет вам почту, вам может потребоваться либо установить почтовый агент, чтобы просмотреть выходные данные из заданий резервного копирования, либо запустить их с выходом, перенаправленным в файл журнала. Например, вы можете использовать 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 не изменит домашнюю среду, которая вызывает проблемы:
$ sudo env | grep ^HOME
HOME=/home/user
$ gksu env | grep ^HOME
HOME=/root
У меня была такая же проблема и я решил ее добавить, добавив свое имя пользователя в группу crontab.
Изменить /etc/group Найти строку, содержащую crontab (должна быть только одна строка). Добавить имя пользователя в конце (если другие пользователи находятся на линии, разделяются запятой) rebootУ меня была аналогичная проблема, которая дала мне довольно бегство. Предполагая, что cron, crontab и anacron являются здоровыми, ключевым признаком является то, что задача выполняется правильно, если вызывается с помощью кнопки «запустить сейчас» gnome-schedule, но не запускается по расписанию один раз.
Это получается быть главным образом проблемой графической среды. Моя рекомендация - создать оболочку для сценария задачи, например. «task-wrapper»:
#!/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 является нечеткой, MESSAGE объясняет, что сценарий запрашивает авторизацию, и «set -e 'гарантирует, что сценарий отменяется, если пользователь нажимает «Отменить». Остальная часть скрипта может использовать простые вызовы 'sudo', которые будут успешными, если между командами не будет много времени.
В Ubuntu 12.04 членство в группе crontab кажется не обязательным.