почему мой crontab не сработал?

<p>я использовал <code>crontab -e</code> чтобы добавить следующую строку в мой crontab:</p><pre><code>* * * * * echo hi >> /home/myusername/test </code></pre><p>тем не менее, я не вижу, чтобы тестовый файл был записан в. это проблема с правами доступа или crontab работает неправильно?</p><p>я вижу, что процесс cron запущен. как я могу отладить это?</p><p><strong> редактировать </strong> - спросите, что у ubuntu есть <a href="https://askubuntu.com/questions/23009/reasons-why-crontab-does-not-work">хороший вопрос о crontab</a> , к сожалению, это все еще не помогает мне.</p><p><strong> редактировать 2 </strong> - хм, кажется, мой тестовый файл имеет 214 строк, что означает, что за последние 214 минут он записывался в каждую минуту. я не уверен, в чем была проблема, но она, очевидно, ушла.</p>

<p>существуют реализации <code>cron</code> (не все из них, и я не помню, какие из них были вручную, но я встречал их в linux), которые каждую минуту проверяют наличие обновленных файлов crontab и не учитывают новые записи до следующей минуты. таким образом, для запуска crontab может потребоваться до двух минут. это может быть то, что вы заметили.</p>

<p>вы добавили <a href="https://serverfault.com/q/230370/67116">пустая строка после вашего cronjob</a> ?</p>

<p>у меня была такая же проблема - рабочий crontab внезапно остановился после того, как я добавил новую запись в конце. оказалось, что я забыл поставить новую строку после этой последней строки.</p><p>я узнал, выдав команду</p><pre><code>cat /var/log/syslog | grep crontab </code></pre><p>и вывод показал проблему:</p><pre><code>jul 2 08:16:01 shiva cron[1254]: (*system*) reload (/etc/crontab) jul 2 08:16:01 shiva cron[1254]: (*system*) error (missing newline before eof, this crontab file will be ignored) </code></pre><p>добавление новой строки и сохранение исправили проблему.</p>

<p>похоже, это исправлено. в следующий раз попробуйте войти в stderr. следующее будет только входить в stdout, а не в stderr:</p><pre><code>* * * * * echo hi >> /home/myusername/test </code></pre><p>постарайтесь убедиться, что есть и явное предложение для stderr. в противном случае stderr может быть отправлен пользователю по электронной почте (при условии, что электронная почта работает) или может вообще не отправиться, в зависимости от конфигурации cron.</p><pre><code>* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr </code></pre><p> <a href="https://serverfault.com/questions/137468/better-logging-for-cronjob-output-using-usr-bin-logger">мое предпочтение</a> - отправлять вывод cronjob в системный журнал. таким образом, я использую преимущества любой существующей инфраструктуры системного журнала (централизованные системные журналы, splunk, ротация журналов уже поддерживается, легко сравнивать сообщения в/var/log/messages &/var/log/cronjob и т.д.), и я не рассылать сисадминам (мне) ненужные электронные письма.</p><pre><code>* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob </code></pre>

<p>у меня проблема была в том, что скрипт не был исполняемым. у меня была <em>crontab -e</em> такая настройка</p><pre><code>* * * * * /bin/my-script.sh </code></pre><p>и файл myscript не был исполняемым, поэтому я запустил</p><pre><code>chmod +x my-script.sh </code></pre><p>сразу же я начал видеть результат, как ожидалось.</p>

<p>я мог бы предположить, что одной из причин этого может быть то, что каталог/home/зашифрован, и когда пользователь вышел из системы, cron не может ничего сделать в этом каталоге.</p><p>см .: <a href="https://stackoverflow.com/a/40354269/1279002">https://stackoverflow.com/a/40354269/1279002</a> </p>

<p>ваша строка cron отлично работает на моем компьютере, когда я изменяю <code>myusernae</code> на <code>phunehehe</code>. есть несколько способов узнать, что не так с вашей системой.</p><p>крон обычно отправляет почту пользователю, когда что-то не так. если вы видите сообщение "у вас есть почта", используйте почтовый клиент для <a href="https://unix.stackexchange.com/q/9141/250">проверьте ваш почтовый ящик</a> . или, проверьте в вашем домашнем каталоге, может быть файл с именем <code>dead.letter</code> там.</p><p>ты можешь проверить <code>/var/log/</code> для записей, относящихся к cron. на моем компьютере файл журнала находится на <code>/var/log/cron/current</code> (требуется root-доступ).</p><p>если у вас есть root-доступ, вы можете остановить демон cron и запустить его в режиме отладки. например, я бы использовал (замените <code>fcron</code> на имя вашего демона):</p><pre><code>killall fcron fcron --foreground --debug </code></pre>

<p>скорее всего, когда происходит сбой cron, он генерирует электронное письмо с идентификатором пользователя задания cron на этом компьютере. если на вашем компьютере не работает mta, или вы не читаете и не пересылаете эту почту куда-то еще, вы не увидите это сообщение, даже если mta работает.</p><p>хороший способ получить ошибки вашего crontab по почте - сделать так, чтобы ваш crontab выглядел так:</p><pre><code>mailto="myemail@example.com" * * * * * echo hi >> /home/myusernae/test </code></pre><p>очевидно, используйте свой адрес электронной почты, а не myemail@example.com. это говорит cron отправлять ошибки на ваш адрес электронной почты, а не на локальную учетную запись. в частности, это полезно, если у вас есть корневой crontab (или фрагмент crontab в /etc/cron.d), который вы хотите просто отправить вам, вы можете избежать спама в почтовом ящике root или адресе переадресации root.</p>