Вопросы Теги

Выполнение Cron не выполняется в любое время, кроме значения по умолчанию * * * * *

В Ubuntu 11.10 (Oneiric Ocelot) мое задание cron работает нормально, если я использую значение по умолчанию

* * * * *

Но если я хочу, чтобы он работал в 17 часов или любой в другой раз он никогда не запускается. Мои настройки: 

00 17 * * * wget http://www.abc.com/a.php

Я также попытался: 

00 17 * * * root wget http://www.abc.com/a.php

Я также попытался указать путь. Существует возврат каретки, и я зарегистрирован как root

. Вот мой полный crontab: 

TZ=Australia/Sydney
22 7 * * * /usr/bin/wget http://www.abc.com/a.php
22 7 * * * /bin/date >> /tmp/date.txt

---- the out is as follss: 

root@Scrunch:~# sudo crontab -l -u root
55 12 * * * date >>/tmp/crontest.txt





root@Scrunch:~#

Почему терминал выводит столько пустых строк после вывода записей crontab? вы подозреваете, что вам не нужны лишние линии каретки .... И я не ввел никаких записей в любые другие cron-пространства, такие как .d, / daily eyc.,

1
задан 30 May 2012 в 22:15

14 ответов

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 25 July 2018 в 18:43

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 25 July 2018 в 18:43

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 2 August 2018 в 00:52

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 2 August 2018 в 00:52

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 4 August 2018 в 16:23

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 4 August 2018 в 16:23

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 6 August 2018 в 01:02

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 6 August 2018 в 01:02

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 7 August 2018 в 18:29

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 7 August 2018 в 18:29

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 10 August 2018 в 07:10

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 10 August 2018 в 07:10

, если ваше задание задания cron недействительно, оно будет зарегистрировано в /var/log/syslog. Обычно я делаю задание cron для запуска через 2 минуты, затем tail -f /var/log/syslog и убедитесь, что все работает как ожидалось.

Если в /var/log/syslog нет ошибок, но команда не выполнена для запуска (или даже его успеха), cron отправит вам по электронной почте консольный вывод из командной строки. Если вы не получаете эти электронные письма (вы можете посмотреть в /var/spool/mail/root), то что-то еще происходит не так. Я замечаю, что вы не используете ключ -Q для wget, поэтому вы должны получать электронную почту каждый раз, когда она запускается.

Наконец, 6-е поле (где вы вставляете root в свой третий пример) действителен только в системном файле crontab (/etc/crontab или в любом из каталогов фрагментов /etc/cron.{d,hourly,daily,weekly,monthly}. Он недопустим для crontab пользователя (который, кажется, используется вами) .

Я сделал следующее, чтобы подтвердить, что все работает правильно в принципе, вы можете следовать этой процедуре, чтобы хотя бы убедиться, что мы делаем то же самое:

  1. Станьте root (обычно я sudo -i). Это потому, что вы говорите, что хотите сделать это как root.
  2. crontab -e. Вы будете помещены в редактор для редактирования crontab файл.
  3. Добавьте следующую строку (отрегулируйте по местному времени так, чтобы она продолжалась в течение следующих 3 минут. Дайте себе некоторое время, чтобы закончить ввод и сохранение файла). 05 10 * * * date >>/tmp/crontest.txt
  4. Удалите или закомментируйте все остальное в файле crontab.
  5. Сохраните файл и выйдите из редактора
  6. Подтвердите, что cron был корректно установлена ​​при запуске crontab -l
  7. Подождите, пока настроенное время
  8. подтвердит, что строка в этом списке отображается в / var / log / syslog:

May 30 10:05:01 snowflake CRON[4170]: (root) CMD (date >>/tmp/crontest.txt)

Наконец, подтвердите, что /tmp/crontest.txt был создан и содержит запланированное время / дату.

Cron уже много лет работает в Unix / Linux, он проверен и надежен, поэтому то, что вы испытываете, не является ошибкой, и вы, кажется, делаете все правильно, поэтому должно быть чем-то другим, что влияет на его функционирование правильно. Надеюсь, мы сможем определить, что это такое с некоторыми диагностическими процедурами:)

1
ответ дан 15 August 2018 в 19:09
  • 1
    нет ошибок в syslog, но команда не запускается, но я вижу почту в / var / spool / mail / root. но это только для * * * * *. он не работает в любое время. только сейчас я проверил местное время Сиднея 6.36 AM | 36 6 * * * / usr / bin / wget abc.com/a.php . oops it failed again – Raghu 30 May 2012 в 01:36
  • 2
    Что произойдет, если вы удалите переменную TZ? Вы видите что-либо в / var / log / syslog? Вы должны увидеть что-то вроде этого: CRON[XXXXX]: (root) CMD ( /usr/bin/wget abc.com/a.php), если вы его не видите, это значит, что что-то еще не так. FWIW, ваша линия cron сама (36 6 * * * whatever-command) правильна, поэтому проблема должна лежать в другом месте. – roadmr 30 May 2012 в 04:49
  • 3
    TZ фактически удаляется, моя система в любом случае настроена на Новый Южный Уэльс / Сиднейский часовой пояс. Точка за исключением по умолчанию ***** cron не работает. еще одно наблюдение, если я использую конфигурацию * / x, тогда она работает. пожалуйста, предложите мне синтаксис для запуска задания cron за раз: 12 и 17 часов – Raghu 30 May 2012 в 14:27
  • 4
    Я обновлю свой ответ, потому что то, что я пробовал, слишком длинное для комментария. – roadmr 30 May 2012 в 19:06
  • 5
    Хорошо, в редактировании, которое вы пытались ответить, мы видим следующее: May 31 00:55:01 Scrunch cron[27182]: (index.html) ORPHAN (no passwd entry). Это означает неправильную запись crontab, в которой cron считает, что index.html является пользователем. Я предлагаю вам дважды проверить ваш синтаксис или обновить свой вопрос с помощью вывода sudo crontab -l -u root, чтобы мы могли видеть все записи, которые есть, и попытаться их исправить. Кроме того, этот может находиться в одном из общесистемных файлов crontab, если вы изменили какой-либо файл / etc / crontab /, /etc/crontab.d/* или / etc / crontab. { ежечасно, ежедневно, еженедельно, ежемесячно}, пожалуйста, проверьте их также. – roadmr 30 May 2012 в 20:42

Используйте только один ноль в течение минуты. Как правило, это хорошая идея при создании заданий cron для использования полного пути команды, которую вы используете. Это связано с тем, что задания cron запускаются в специальной очень ограниченной среде оболочки, и ваш путь может отличаться от того, что вы используете при входе в систему. Если вы этого не знаете, вы можете легко найти его с помощью команды: 

which wget

Другое дело, последняя команда root wget http://www.abc.com/a.php неверна. root не является допустимой командой. Я предполагаю, что вы хотели использовать sudo. Это было бы лишним, если вы выполняете задание cron как root, т. Е. 

sudo crontab -e
1
ответ дан 15 August 2018 в 19:09
  • 1
    Я только хотел добавить его к вашему вопросу, а не удалять все остальное. :-) В любом случае, я думаю, вам нужно удалить TZ=Australia/Sydney. Это не обязательно, поскольку cron будет работать как любой часовой пояс, который пользователь в любом случае, и я думаю, что это может вызвать проблему. – reverendj1 30 May 2012 в 02:33
  • 2
    Я очень взволнован, и, не будучи в состоянии просто болтать, это доказывает, что это крутой орешек. Это должно быть действительно действительно просто. – reverendj1 30 May 2012 в 02:45

Другие вопросы по тегам:

Похожие вопросы: