Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: [РЕШЕНО]Не работает запуск bash скрипта через cron в Ubuntu Server 9.10  (Прочитано 12359 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Siegfrid

  • Автор темы
  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
Перепробовал все возможные варианты. пробовал запускать крон из под root и user, прописывал переменные окружения, запускал профайлы, бегал с бубном... ничего не помогает...
Скрипт и команда для крона проверялись из под bash, все работает корректно!

Подскажите, как сделать запуск скрипта. Какие логи посмотреть?

Настройки крона:
katalon@katalon:~$ crontab -l
#
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
*/2 * * * * . /user/katalon/.profile; katalon bash /home/katalon/backup/main_backup.sh
#

Сам скрипт:
#!/bin/bash
#cron settings:
# issue this command: crontab -e

#settings
EMAIL="test@test.ru"
DATE=`date +%Y%m%d-%H%M%S-%Z`
PREFIX=`date +%m-%Y`
DATADIR=/home/katalon/backup

#создаем каталоги для mysql
mkdir -v $DATADIR/db 2> /dev/null
mkdir -v $DATADIR/db/$PREFIX 2> /dev/null

#создаем каталоги для архивов
mkdir -v $DATADIR/archives 2> /dev/null
mkdir -v $DATADIR/archives/$PREFIX 2> /dev/null

#создаем каталоги для логов
mkdir -v $DATADIR/log 2> /dev/null
mkdir -v $DATADIR/log/$PREFIX 2> /dev/null

#исполняем файлы
/home/katalon/backup/backup_katalon.sh | tee /home/katalon/backup/log/$PREFIX/backup_katalon_$DATE.log
/home/katalon/backup/backup_gulvar.sh | tee /home/katalon/backup/log/$PREFIX/backup_gulvar_$DATE.log
/home/katalon/backup/backup_mail.sh | tee /home/katalon/backup/log/$PREFIX/backup_mail_$DATE.log

if [[ $? -gt 0 ]];then
echo "[++++++----][`date +%F--%H-%M`] Aborted. backuping is failed."
exit 1
fi
#Send email
#echo "Backup is done" | mailx $EMAIL -f backup_katalon.log backup_gulvar.log backup_mail.log -s  "MySQL Backup is done at $DATE"
echo "Backup is done" | mailx $EMAIL -s  "MySQL Backup is done at $DATE"
exit 0
« Последнее редактирование: 06 Март 2010, 10:23:38 от Siegfrid »

Оффлайн Mam(O)n

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 5855
    • Просмотр профиля
Обрати внимание на файл /etc/crontab

Оффлайн Siegfrid

  • Автор темы
  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
Обрати внимание на файл /etc/crontab

А можно чуть больше раскрыть мысль.

Оффлайн Mam(O)n

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 5855
    • Просмотр профиля
Туда вставь строчку запуска по образу и подобию того, что там уже прописано, до последнего знака #

Оффлайн mazut

  • Активист
  • *
  • Сообщений: 564
  • да, не заходи ты сюда!
    • Просмотр профиля
cron после знака % представляет как переход на новую строку, поставь Backslash '\' перед каждым символом.

http://www.hcidata.info/crontab.htm
Патрикеич.
Под наблюдением.

Оффлайн Mam(O)n

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 5855
    • Просмотр профиля
cron после знака % представляет как переход на новую строку, поставь Backslash '\' перед каждым символом.
В его кронтабе этого нет а в скрипте это не надо править.

Оффлайн wl

  • Старожил
  • *
  • Сообщений: 1393
    • Просмотр профиля
Была тут уже подобная тема, человек точно с тем же самым мучался.

Там у Вас трубопроводы используются (pipes, посредством > и |), на это bash-ем выделяется память, и ее, бывает, не хватает.
На свете феньки есть такие, брат Горацио, которых лохи просто не секут. (Шекспир, "Гамлет", вольный перевод)

Оффлайн Mam(O)n

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 5855
    • Просмотр профиля
Ну вот в другом месте то её хватает. Неужели у ТС 16 мегабайт всего набортной памяти?!

Я вот про другое слышал, что крону может не хватить памяти, когда в stdout из скрипта много данных выстреливается. Крон их по моему копит и буфер этот ограничен. Поэтому на конце команды обычно делают перенаправление в лог или в /dev/null. Например: backup_me.sh >/dev/null 2>&1

Оффлайн Siegfrid

  • Автор темы
  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
Планирую сделать ход конем, попробовать простенький скрипт запустить, а то это действительно делает дампы БД. Посмотрю, что с ним будет, если проблема останется, то значит дело не в скрипте.

Реально перепробовал кучу вариантов, пока что никаких положительных результатов и что обидно, ошибку по логам тоже не найти...

Оффлайн mazut

  • Активист
  • *
  • Сообщений: 564
  • да, не заходи ты сюда!
    • Просмотр профиля
Дело не в скрипте

Возникает проблема если Shell отличается от Loginshell

правим

sudo gedit /etc/crontab

*/2   * * *   root  /bin/bash --login /path/skript.sh



Патрикеич.
Под наблюдением.

Оффлайн Siegfrid

  • Автор темы
  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
Дело не в скрипте

Возникает проблема если Shell отличается от Loginshell

правим

sudo gedit /etc/crontab

*/2   * * *   root  /bin/bash --login /path/skript.sh

В общем удалось победить проблему.

 Во первых у меня была команда `date +%F`в кроне, с ее помощью я хотел задавать уникальные имена для файлов лога, но видимо она не очень то нравилась самому крону, хотя shell ее нормально кушает. Ее я убрал.

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

Еще правда я прописал в своем скрипте вызов других скриптов через bash и для всех команд в конце указал дополнительно 2 > /dev/null (я так понимаю, это перенаправление ошибок в лог, давно не писал ничего под bash)

В целом, что конкретно помогло, сказать затрудняюсь, больше грешу на `date +%F` (на простеньком скрипте было хорошо видно, что эта команда не нравилась крону), хотя я пробовал и без нее, видимо что то еще являлось проблемой. Чудеса, да и только...

Всем спасибо за помощь!

Оффлайн Mam(O)n

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 5855
    • Просмотр профиля
Во первых у меня была команда `date +%F`в кроне
Вот о самом главном промолчал. А mazut у нас экстрасенс оказался. Или просто в теме.

в конце указал дополнительно 2 > /dev/null (я так понимаю, это перенаправление ошибок в лог, давно не писал ничего под bash)
Это перенаправление ошибок на йyк. Так, к сведению.

В целом, что конкретно помогло, сказать затрудняюсь, больше грешу на `date +%F`
Читай коммент №4

Оффлайн Siegfrid

  • Автор темы
  • Новичок
  • *
  • Сообщений: 5
    • Просмотр профиля
Во первых у меня была команда `date +%F`в кроне
Вот о самом главном промолчал. А mazut у нас экстрасенс оказался. Или просто в теме.

в конце указал дополнительно 2 > /dev/null (я так понимаю, это перенаправление ошибок в лог, давно не писал ничего под bash)
Это перенаправление ошибок на йyк. Так, к сведению.

В целом, что конкретно помогло, сказать затрудняюсь, больше грешу на `date +%F`
Читай коммент №4

Ух ты, точно, я как то сразу сам не догодался про backslash, совсемголова дурной слала, надо будет попробовать сегодня :)

Пользователь решил продолжить мысль 06 Март 2010, 10:22:59:
Во первых у меня была команда `date +%F`в кроне
Вот о самом главном промолчал. А mazut у нас экстрасенс оказался. Или просто в теме.

в конце указал дополнительно 2 > /dev/null (я так понимаю, это перенаправление ошибок в лог, давно не писал ничего под bash)
Это перенаправление ошибок на йyк. Так, к сведению.

В целом, что конкретно помогло, сказать затрудняюсь, больше грешу на `date +%F`
Читай коммент №4

Ух ты, точно, я как то сразу сам не догодался про backslash, совсемголова дурной слала, надо будет попробовать сегодня :)

В общем backslash решил проблему с вызовом date из crontab!
Всем спасибо за помощь!!!
« Последнее редактирование: 06 Март 2010, 10:22:59 от Siegfrid »

 

Страница сгенерирована за 0.058 секунд. Запросов: 22.