Когда я root - cron не выполняет бэкапы

Почему письма, а не логи? cron ведь про каждое запущенное задание пишет в лог, что запустил его. И почему такое странное задание, почему не абсолютный путь?

Пару минут назад пришло письмо (18:20 по московскому).

Там cat /var/log/syslog пустота.

Там cat /var/log/syslog.1 последнее событие вчерашнее.

Nov  5 21:00:00 k0ttee CRON[5403]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))

А разве отправка писем отменяет логи? O_o

Не должна она мешать. Что-то ты нам недоговариваешь. Или что-то в твоем скрипте глючит, и он ждет, пока не закончится сессия рута.

В скрипте ничего особенного, архивация содержимого /etc и отправка получившегося архива средствами curl на yandex-disk.

http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_03.html

Ерунда какая-то. В лог должно каждый час сыпаться:

CMD (   cd / && run-parts --report /etc/cron.hourly)

Или вы редактировали crontab, отключали лишние логи?

1. Вам уже написали. Абсолютный путь! Я вообще хз как относительный должен отработать.
2. Скрипт backuper.sh покажем?

cron ведь про каждое запущенное задание пишет в лог, что запустил его

FYI Не обязательно.

Вы ОС ТС увидели? И я не увидел. Поэтому не обязательно.

./backuper.sh

может всё-таки

~/backuper.sh

Я руками лазил (куда не положено и как не положено). Дефолтное содержимое не правил, только пытался добавить свою строку.

nano /etc/crontab

Потом открыл и добавил свою строку (как положено и куда положено)

crontab -e

Системные задания обычно и пишут в /etc/crontab (простым редактировнием). ″crontab -e″ для пользовательских файлов, root'а обычно туда не засовывают.

Системные задания обычно и пишут в /etc/crontab

Да хтож вам такое рассказал? А если у меня нэма такого? у меня уже не linux?
Прошу прощения за «высокий слог» но действительно нельзя говорить об «обычно»... Вас я лично уважаю за знания.

В топку crontab, сделайте через юниты timer и service, и будет зашибись.

Вас я лично уважаю за знания.

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

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

20 * * * * /root/backuper.sh

Абсолютный путь!

Относительный, от root, работает... Но, только когда я не сижу через ssh под пользователем root.

Переписал на абсолютный путь.

/root/backuper.sh

Повесил в ssh-сессии редкий ping (чтобы сессия не закрылась), накатил перцовки с медом из трехлитровой банки (болею в соплях, хнык).

Спустя час времени (часы синхронны домашнему компуцтеру) задание cron не выполнилось.

Вывод: абсолютный путь это хорошо, он точно не промажет... Но, не помогло.

Скрипт backuper.sh покажем?

Не просто покажем! Покажем с превеликим быдлокодерским эксбиционизмом! Я же не корпорация зла, чтоб скрывать быдлокод :)

#!/bin/bash
CLOUD_PATH="https://webdav.yandex.ru/ServersBackups/" #облако (включая путь)
CLOUD_USER="" #логин
CLOUD_PASS="" #пароль
FS_FOLDERS="/etc /root /home /var/www" #какие директории бэкапить
SERVER_NAME=$(hostname -s) #имя сервера = взять имя машины
TIME=`date +%Y-%m-%d` #время создания копии: год-месяц-день
FS_FILE=/tmp/$SERVER_NAME-files.$TIME.tar.gz #локальное место архива (до заливки)
tar -czf $FS_FILE -P $FS_FOLDERS #архивация
curl --user $CLOUD_USER:$CLOUD_PASS -T "$FS_FILE" $CLOUD_PATH #заливка
unlink $FS_FILE #удаление локального архива

юзера указать забыл.

Может еще и пароль выложить на форум? :)

В топку crontab

Если слать в топку, тогда уж сразу весь cron. Однако на кроне зиждится, ну например, сброс сессий php.

cat /etc/cron.d/php

# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean

сделайте через юниты timer и service, и будет зашибись

Кроме синтаксического сахара (даты пишутся в человекопонятную сторону) еще какие-нибудь зашибательства есть?

Я вообще хз как относительный должен отработать

Как обычно. В данном случае брать из cwd, которая скорее всего /root.

Почему письма, а не логи? cron ведь про каждое запущенное задание пишет в лог, что запустил его

Потому что у ТС не запускает и посылает вывод команды (ошибку) на почту юзеру.

тут же приходит письмо от крона

И что в письме написано?

чтобы моя SSH-сессия под рутом не мешала работать крону?

Я так понимаю, что у тебя всё как раз наоборот - когда ты залогинен, то работает. Или так и задумано, что backuper.sh должен давать какой-то вывод при нормальной работе?

Простите. Но я это написал как раз для того что бы не посчитали тролингом. Был не правильно понят.

Но ведь он прав, если речь про /etc/crontab

Однако на кроне зиждится, ну например, сброс сессий php.

Оставьте легаси на совесть мейнтейнеров.

еще какие-нибудь зашибательства есть?

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

В смысле не запускает?

Ведь у него то приходят бекапы, то нет. И ещё есть /etc/cron.d/php, вроде как дистрибутивный без изменений. Почему в логе есть только:

(root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))

В смысле не запускает?

В прямом смысле. Крон не находит команду которую нужно запустить и по почте отправляет ошибку. Это просто в рамках телепатии, т.к. ТС не сказал что там на почту ему идёт, отчёт об ошибке или валидный вывод команды, но обычно, чтобы не засирать почту валидный вывод направляют куда-то в лог.

Странные у вас и у ТС crond, поделитесь версий. Они, в отличии от обычного поведения, смотрят, есть ли исполняемый файл, а обычный crond просто вызывает шелл (sh) и кормит ему всю строку, не изучая, что там, команды шелла или исполняемый файл. И получает, фактически от шелла, stderr+stdout, если он есть, пишет об этом в лог, отправляет мыло.

То есть, если в /etc/crontab написать:

*  *  *  *  *  root /no-file

(root) CMD (/no-file)

И ещё ваши crond, они умеют выборочно логгировать запускаемые задания. У ТС в логах нет строки

(root) CMD [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean

но это никого не удивляет.

Странные у вас и у ТС crond, поделитесь версий.

Не помню в каком дистре и какой версии, но было что толи stderr то ли stdout в /dev/null отправлялось. Правда давно это было.

″crontab -e″ для пользовательских файлов, root'а обычно туда не засовывают

А я всегда везде через crontab -e делал, даже не парился

ТС покажи
ls -l /root/backuper.sh

ИМХО, удобнее, когда все задания системного администратора в одном месте. А так как имеет смысл часть заданий делать не от root (например, vacuum analize в постгресе), то уж и записывать всё в /etc/crontab, там и пользователя видно, чтобы не вспоминать, как он называется (psql, pgsql, postgres...).

С правами на файл у ТС должно быть нормально, с его слов все работает, если нет открытых сессий. Наверное, нужно делать strace процесса crond.

с его слов все работает, если

ага, тут половина топиков начинается с «верьте мне на слово, я всё сделал и настроил правильно на первом шаге, а теперь какая-то чёрная магия происходит ни с того, ни с сего»

Коллеги все это конечно так. Но вот если вернуться к изначальной проблеме ТС, работает если рут НЕ залогинен. Мне самому уже интересно шо за магия пошла. :)

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