CRONTAB не завершает работу svndump

Я только что обнаружил, что автоматические дампы, которые я создавал в моем репозитории SVN, рано обрезаются, и в основном только половина дампа есть. Это не чрезвычайная ситуация, но я ненавижу находиться в этой ситуации. Это в первую очередь поражает цель создания автоматизированных резервных копий.CRONTAB не завершает работу svndump

Команда, которую я использую, приведена ниже. Если я выполняю его вручную в терминале, он завершает штраф; файл output.txt имеет размер 16 мегабайт со всеми 335 версиями. Но если я оставлю его к кронтабу, он подпишет на полпути, примерно в 8,1 мегабайта и только первые 169 ревизий.

# m h dom mon dow command 
18 00 * * * svnadmin dump /var/svn/repos/myproject > /home/andrew/output.txt

Я на самом деле сохранить датированного сжатые файлы, и нет недостатка места на сервере, так что это не проблема дискового пространства. Кажется, это залог через две секунды, так что это может быть проблемой времени, но размер файла один и тот же каждый раз за последний месяц, поэтому я не думаю, что это так. Выполняется ли crontab в ограниченном пространстве памяти?

источник

2010-02-24 Andrew

Итак, я не знаю, какова настоящая проблема, но если я проещу STDERR из svnadmin в/dev/null, когда я сделаю свалку, все будет хорошо. Я попытался использовать «тихий» флаг (-q), и он также преуспевает. Я предполагаю, что, когда скрипт оболочки, запущенный из crontab, обнаруживает достаточно текста в STRERR, он прекращает выполнение того, что он запускает, и переходит к следующей инструкции. Я сделал MD5 в ручном файле и запланированном файле, и они идентичны. Это, похоже, решено. Поэтому, если кто-либо сталкивается с этой проблемой самостоятельно, это сценарий оболочки, который я использовал, чтобы успешно пройти предыдущее усечение. Это немного подробный. Сожалею.

#!/bin/sh 
echo "STARTING AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt 
rm /tmp/andrewMobileApp.dump 
svnadmin dump /var/svn/repos/andrewMobileApp > /tmp/andrewMobileApp.dump 2>/dev/null 
echo "svnadmin exited with code $?" >> /home/andrew/svnlog.txt 
gzip -c /tmp/andrewMobileApp.dump > "/home/andrew/svnbackups/andrewMobileApp.dump.$(date +\%Y\%m\%d\%I\%M\%S).txt.gz" 
echo "gzip exited with code $?" >> /home/andrew/svnlog.txt 
echo "DONE AT $(date +\%Y/\%m/\%d/T%I:\%M:\%S)" >> /home/andrew/svnlog.txt 
echo "-----" >> /home/andrew/svnlog.txt

Этот скрипт вызывается через супер-пользовательский crontab.

источник

2010-02-27 07:39:29 Andrew

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

источник

2010-02-24 05:50:41 sha

Я не думаю, что ограничение по размеру является фактором здесь. Хотя файл был отключен на полпути, в каталоге было 20 одинаковых резервных копий одинакового размера. Я попытался сбросить/tmp, и он обрезается в той же точке. Crontab также выполняется на уровне суперпользователя, поэтому он должен иметь довольно свободный доступ к файловой системе. – Andrew

Еще одна мысль: - Попробуйте обернуть вызов svnadmin в shell scrtipt. Добавьте отметки даты и времени до и после вызова svnadmin. Перенаправить вывод в некоторый файл журнала. Также записывайте код результата svnadmin. Это даст вам некоторое представление о том, насколько успешным был призыв svnadmin и сколько времени это заняло. - Попробуйте перепланировать эту задачу в другое время (у меня есть некоторые сумасшедшие ошибки cron, связанные с конкретной датой и временем выполнения). – sha

Конечно, когда я захватил код возврата в сценарии оболочки, svnadmin dump возвращается с «0», когда я sudo-исполняю его вручную, но он возвращается с «1», когда это делает crontab. Я также зарегистрировал/usr/bin/id, и информация там одинакова как для меня, так и для crontab. Сценарий запускается в идентичных контекстах пользователя. Должно быть какое-то значение конфигурации crontab, которое я не вижу здесь.Ничто из этого не имеет для меня никакого смысла. Я буду рыть. – Andrew

Прежде всего, убедитесь, что svnadmin находится в переменной окружения PATH задания cron. Возможно, вам придется указать полный путь для /usr/bin/svnadmin или что-то подходящее.

Кроме того, вместо svnadmin dump, вы можете ознакомиться с svnadmin hotcopy, который предназначен для резервного копирования репозитория.

источник

2010-02-24 05:51:11 Avi

Я попытался добавить абсолютный путь, но не имеет значения. svnadmin _is_ executing, он просто не заканчивается. Я хотел избежать использования hotcopy, потому что он не такой портативный. Я могу (потенциально) захватить дамп репозитория и использовать его для создания ночного моментального снимка сервера в случае сбоя оборудования. Ну, это идея в любом случае. – Andrew

Попробуйте выполнить стандартную ошибку команды в файле, чтобы вы могли видеть, сообщает ли она об ошибке. – Avi

Я не вижу никаких исключений или ошибок. Я включил регистрацию системы cron и, похоже, выполнил ее нормально: Feb 24 01:12:01 desktop/USR/SBIN/CRON [25399]: (root) CMD (/ usr/bin/svnadmin dump/var/svn/repos/myproject> /home/andrew/output.txt) Я также попробовал добавить '&' в конец инструкции, чтобы увидеть, будет ли форсировать его больше времени для выполнения. Не уверен, что это даже имеет смысл в кронтабе, но это не имело никакого эффекта. – Andrew

Я представил это как ошибку в пакете cron Debian, так как я тоже там его испытывал (под vserver). См. Ошибку # 577133 в Debian. Кристиан Кастнер исправил ошибку, добавив код, чтобы обойти весь код обработки почты, если MTA не найден.

источник

2010-04-22 23:37:10

ответ

Смежные вопросы