Команда mysqldump не работает в задании cron
short: no
long:
terminfo описывает функции терминала. Эти конкретные возможности, вероятно, были добавлены в список возможных возможностей терминалов AT&T в конце 1980-х для описания какого-то давно забытого терминала, который не использовал ^S и ^Q.
curses вообще (ncurses конкретно) не обращает внимания на эти особенности (потому что ими никто не пользуется). stty не обращает на это никакого внимания по другой причине: она игнорирует терминальную базу данных, являясь, по существу, зависимой от платформы программой с жестко запрограммированными знаниями для заполнения случаев, когда требуется начальное значение по умолчанию.
Проблема в том, что в последней строке скрипта нужно указать полный абсолютный путь к файлу tables.txt, иначе задание cron не сможет его найти.
Причина, по которой скрипт работает, когда вы запускаете его вручную, заключается в том, что файл tables.txtнаходится в текущем каталоге, поэтому у системы нет проблем с его поиском.
Я исправил путь к таблицам.txt, но проблема осталась, но после перенаправления std err 2>&1 все заработало. Причина, по которой я обнаружил, что предупреждающее сообщение «Предупреждение :Использование пароля в интерфейсе командной строки может быть небезопасным». создает проблему. После этого сообщения mysqldump выходит, поэтому я перенаправил ошибку, и она начала работать. Я заметил это после обновления mysql до 5.6.
#!/bin/bash
echo "Hello"
while read table
do
touch sc_back/${table}.sql
/usr/bin/mysqldump -uroot -pxxxxx CMAYA_RadiusUserLogs $table > /backup /sc_back/${table}.sql
done < /backup/tables.txt
Когда cron выполняет ваш скрипт, текущим рабочим каталогом является домашний каталог пользователя таблицы cron (, по-видимому, /root ), а ваш скрипт с его файлами находится в /backup. Вот почему скрипт не может найти table.txt, а цикл таблицы не имеет итераций.
Вы должны сначала перейти в каталог скрипта, а затем выполнить его, например:
58 16 * * * root cd /backup && /bin/sh -x call_backup.sh > backup.log