10 мая 2005 в 15:39
Запустил новый сайт на друпале. Хостинг - Мастерхост. Попросил службу поддержки сделать мне запуск cron.php два раза в сутки.
Саппорт прописал следующие команды:
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.KY5MS3AKJj installed on Mon May 9 00:46:48 2005)
# (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.12.2.4 2001/06/16 03:18:37 peter Exp $)
0 */12 * * * /usr/local/apache-php4/bin/php-cli /home/u22504/motorworld.com.ua/www/cron.php /dev/null 2>&1
MAILTO=admin@comics.com.ua
# (/tmp/crontab.KY5MS3AKJj installed on Mon May 9 00:46:48 2005)
# (Cron version -- $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.12.2.4 2001/06/16 03:18:37 peter Exp $)
0 */12 * * * /usr/local/apache-php4/bin/php-cli /home/u22504/motorworld.com.ua/www/cron.php /dev/null 2>&1
MAILTO=admin@comics.com.ua
Спустя несколько дней проверил - крон вроде бы не отработал. ПО крайней мере поиск не работает (если вручную запустить cron.php - то всё ОК) и в логах друпала следов запуска нет.
В чём грабли?
ЗЫ. Да, ещё такой момент. При запуске вручную cron.php браузер выдает такую строку:
warning: set_time_limit() has been disabled for security reasons in /home/u22504/motorworld.com.ua/www/cron.php on line 14.
Но тем не менее желаемого я достигаю - база поискапереиндексируется. В чём природа ошибки?
Комментарии
Похоже пора в FAQ тему Masterhost+Drupal заводить
Да, функция set_time_limit на .m отключена по причинам безопасности. Workaround: забить, работает в принципе и без неё.
Редактирование крона делается с помощью команды:
$ crontab -e
-- исполнять в командной строке через ssh например. Просмотр задания крона для пользователя:
$ crontab -l
О том как запускать скрипты на php через cron в хелпе пользователя на мастерхосте доходчиво написано, но данный способ не подойдёт, поскольку обращаться к cron.php надо не с localhost, а по полному имени сайта. См. примеры скриптов в /scripts для wget и curl - в них надо прописать реальное имя сайта вместо примера и поставить на исполнение в кроне вызов одного из этих скриптов, которые и обращаются по ссылке вашсайт/cron.php, но не напрямую к cron.php с локалхоста!
--
Axel,
www.axel.drupal.ru
Axel, если вам не сложно, киньте те скрипты о которых вы говорите сюда на форум или мне на мыло (admin@comics.com.ua). У меня в поставке Друпала их нет. Есть только вот такой: cron-lynx.sh
И ещё, если можно, подскажите правильную команду в кроне, которая будет запускать нужный скрипт, при условии, что он находится в папке scripts Друпала.
Заранее признателен.
Ага... У всех есть а у Вас нет... Специальный дистрибутив сделали noscripts и именно Вам его подсунули.
cron-lynx.sh
cron-curl.sh
Это, как ни странно, они и есть...
Прописывать их так:
0 */12 * * * /home/u22504/motorworld.com.ua/scripts/cron-lynx.sh
Если на .m нет ни lynx, ни curl, то можно воспользоваться _одной_из_ следующих строк
1. Если есть wget:
0 */12 * * * /usr/bin/wget -q --append-output=/dev/null http://yoursite.ru/cron.php > /dev/null
2. Если есть fetch:
0 */12 * * * /usr/bin/fetch -q -o /dev/null http://yoursite.ru/cron.php > /dev/null
--
USU-Lug http://usu-lug.org.ru
Спасибо. Буду разбираться.
Ещё раз подниму тему.
В *nix ОС я не силён, поэтому такой вопрос: lynx, wget, fetch - это службы? Мне просто в сапорт нужно грамотно вопрос сформулировать о наличии всего этого хозяйства на сервере. 
Или можно как-то и без сапорта проверить есть или нет?
И ещё, раз уж начал писать. Глупый вопрос номер два.
Скрипты .sh можно запускать из любой папки? Какие нужны права (chmod) для скрипта? А то у меня браузер сервер ошибку 403 при попытке запуска из браузера скрипта cron-lynx.sh.
Раз уж связались с хостингом настоятельно рекомендую купить и прочесть какую-нибудь книжку по основам юникса (книг по Linux/*BSD и другим юниксам сейчас в любом техническом книжном можно найти). Избавит от кучи вопросов в будущем.
lynx, wget и пр. - это программы. lynx - текстовый браузер, wget, curl - программы для скачивания файлов. С помощью них имитируется обращение к странице cron.php как если бы это обращался пользователь из браузера. Проверить есть ли программ можно так например:
$ which lynx
- если в ответ выдаст путь вроде /usr/bin/lynx - значит есть, если not found - значит нет такой в пути поиска программ. Отдельно отмечу что на мастерхосте lynx установлен
Исполнять можно из любой папки, нужно только чтобы у файла были права на исполнение выставлены. В данном случае проще всего так:
$ chmod a+x имяскрипта
Тем не менее браузером этот скрипт не исполнить, правильно ошибка выдаётся. Вебсервер сконфигурирован так чтобы вызывать скрипты из веба только если они лежат в определённых папках - это называется cgi. Но в данном случае скрипту не нужно работать через cgi, он вызывается как обычная программа самой операционной системой.
Короче, задачу саппортам следует формулировать так: следует поставить в крон запуск скрипта scripts/cron-lynx.sh, проверив что он является исполняемым.
Если что-то осталось непонятным - см. первый абзац этого комментария
--
Axel,
www.axel.drupal.ru
альтернатива - поставь poormascron (или как он там пишется)
Я вообще не пойму, как понять, правильно ли у меня настроен запуск крона. Т.е. я по логам вижу, что крон выполнялся только тогда, когда я вручную его дергал в браузере. Но его же должен дергать планировщик задач.
Мою бдительность усыпляла рассылка уведомлений об ответах. Но, видимо жто происходит без участия крона. А вот то, что у меня не работали модули subscription и notify (не помню точно какие, -- должны присылать дайджест новых тем на сайте подписчикам), теперь вполне понятно.
Целый год у меня вообще сайт крутился без единой задачи в планировщике. Я почему-то думал, что крон будет выполняться сам по себе
Наконец, я создал задачу в планировщике (в cpanel), настроил ее по образу и подобию, как у товарища, который крутит свои сайты на том же хостинге. Как чайник я конечно не знаю синтаксис команды, которую надо указывать в задаче. Содрал у товарища, изменил только название своей папки в корневой директории:
php -q -f /home/zik95i/public_html/cron.php ../../ cron > /dev/null
3 дня эта задача провисела, но ни разу крон не запустился, хотя должен был запускаться по задумке раз в сутки. Что я сделал неправильно?
В cpanel можно использовать ту строку, которая приведена в файле инсталляции.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
Вставил в cpanel строку из файла инсталляции, но она не сработала, - видимо нету wget в usr/bin/
Зато сработала (как я не заметил эту подсказу в cpanel!??) строка:
GET http://mysite.com/cron.php > /dev/null
Ура
http://www.drupal.ru/node/2293
оч. полезный топик, всем огромное спасибо
во-первых не usr/bin/, а /usr/bin
во-вторых, попробуйте написать просто wget вместо /usr/bin/wget
Скорее всего она есть в /usr/bin, но она вам оттуда недоступна.
Однако ее безопасная версия наверняка существует, но в другой директории, например /usr/locale/sbin
Указывать полный путь к утилите обычно необязательно, поэтому, повторюсь, попробуйте написать просто wget вместо /usr/bin/wget (ну и про параметры, разумеется, не забудьте)
Просто интересно, есть ли все-таки wget у Вас?
P.S. (Кстати, а почему бы Вам не попробовать поискать wget через ssh?)
With best regards, Roma
на сайте motorworld.com.ua и на http://naukastudio.com.ua/portfolio/web/2 - написано что "дизайн", "разработка" "поддержка" студии, это GNU дизайн ДА, а вот разработка НЕТ.... не пудрите мозг народу
[b]"не пудрите мозг народу"[/b]
...
это не в тему, это раз...
а во-вторых как и что говорить - это дело именно разработчиков того или иного сайта... GNU GPL не запрещает менять авторство продукта, эта лицензия запрещает удалять упоминание о том, что это программа распостраняется под GPL...
какой программой будет осуществлен доступ к cron.php: lynx, wget, curl или fetch
нет, разницы нет, главное - запустить скрипт
Спасибо за разъяснения - у меня тоже вопрос отпал
в ручную все ок. а вот автоматом не работает... в е-мыле присылает такое...
/storage/home/userxxx/motorcycles/cron.php: cannot open ?php: No such file or directory
и в догонку...
а это нормально что в самом файле cron.php нет закрывающей скобки ?>
Да.
А зачем вызываете скрипт напрямую? Надо site.ru/cron.php
напрямую - дык это я по FAQ хостера делал. никогда с cron не работал.
прописал как велено... все равно не то...
http://motorcycles.ru/cron.php: not found
motorcycles.ru/cron.php: not found
Почитайте: http://www.drupal.ru/node/2293
если вашь скрипт заприщен для запуска со внешних источников например c помощью .htaccess то запус через lynx у вас работать не будет тк это консольный браузер и он не будет иметь прав на запуск вашего скрипта. я бв рекомендовал закрывать директорию со скриптами для крона с помощью .htaccess и для запуска скриптов в кроне использовать
Цитата:
/usr/bin/php -f "путь к файлу"
Работа в москве
если вашь скрипт заприщен для запуска со внешних источников например c помощью .htaccess то запус через lynx у вас работать не будет тк это консольный браузер и он не будет иметь прав на запуск вашего скрипта. я бв рекомендовал закрывать директорию со скриптами для крона с помощью .htaccess и для запуска скриптов в кроне использовать
Цитата:
/usr/bin/php -f "путь к файлу"
Работа в москве
lynx и не должен запускать скрипт, он должен прочитать страницу. Скрипт запустит друпал.
Пытаюсь настроить cron у себя в cpanel:
cron.php лежит в корне сайта.
/usr/bin/php -q /home/мой_логин/public_html/cron.php
выдает ошибку на почту:
Warning: require_once(): Unable to access ./includes/cache.inc in /home/xxx/public_html/includes/bootstrap.inc on line 1003
Warning: require_once(./includes/cache.inc): failed to open stream: No such file or directory in /home/xxx/public_html/includes/bootstrap.inc on line 1003
Fatal error: require_once(): Failed opening required './includes/cache.inc' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/xxx/public_html/includes/bootstrap.inc on line 1003
Что делать? Насколько я понял - нет доступа
доступ есть но найти нужный файл он не может, потому что include_path не включает Ваш каталог.
дефолтный cron.php расчитан на запуск вебсервером, а тот устанавливает массу переменных соответствующим образом...
нужно немного подправить cron.php.
примерно это нужно добавить в начало cron.php:
$_SERVER['HTTP_HOST'] = 'myserver.net'; // Ваш сервер (имя)
$_SERVER['REMOTE_ADDR'] = '127.0.0.1';
$_SERVER['REQUEST_METHOD'] = 'GET';
chdir('/var/www/myserver.net/htdocs'); // Полный путь на сервере к Вашему http_home
....
все он правильно сказал. хорошим тоном будет запретить запуск cron.php вебсервером (.htaccess) и запускать его непосредственно командой php. все эти танцы с lynx/fetch/curl имеют смысл лишь с удаленного хоста (при отсутствии доступа к крону на локальном).
Для чего собственно? В чём проблема? [D]DOS? Есть и другие, уязвимые для этой атаки места, кроме крона. Хотя про безопасность я не услышал ни слова - хотя бы понятно было. Только про "хороший тон". Править ядро и вмешиваться в его работу без особой необходимости - это "хороший тон"?
20 раз говорено что делать. Я не говорю про поиск, хотябы тред прочитайте со ссылками!
нужно разносторонне смотреть на проблему... хорошим тоном будет убрать лишний костыль (даже 2) в виде запуска браузера из cron-a, обеспечив попутно бОльшую безопасность системы в целом, в добавок убрав бесполезную нагрузку (пусть и мизерную в масштабах одного сайта).
вот тут говорят о lynx... смотрим -
~ $ ps axu | grep lynx
anon 731 0.0 0.5 11596 5420 pts/6 S+ 08:31 0:00 lynx
итого lynx скушал 5МБ оперативки и еще 5 виртуальной памяти зарезервировал. wget меньше - 2(5)МБ..
мелочь конечно, в масштабах одного сайта.
к сожалению нет апача у меня, а то б посчитал сколько он скушает на запрос. хотя тут тоже палка о двух концах...
ядро никто не заставляет править, так как cron.php никакого отношения к ядру не имеет - это лишь скрипт вызывающий функцию ядра.
вот такое у меня видение того, что есть "хороший тон"
Есть ядро, есть сторонние модули. Можно употребить слово дистрибутив, если больше нравиться.
Правка ядра подразумевает создание патчей, т.к. следующее обновление сотрёт все Ваши изменения. Или Вы будуте объяснять клиенту, что обновлять файлик такой-то не надо? Будете вносить в инструкцию по использовании системы замечение о накладываниеи патча на cron.php? Или вы не пишите сопроводительных записок к сайту и не создаёте патчей? Можно и так, но тогда не стоит и изменения вносить в ядро.
Кстати, это не костыль а нормальное решение. А вот Ваше решение - костыль, т.к. требует, лишних телодвижений (в перспективе - много теловижений). Кстати, сколько сожрёт PHP с загруженным друпалом?
Dan
Бессмысленный спор. Dark_kz мог бы создать файл с любым названием следующего содержания:
<?php
$_SERVER['HTTP_HOST'] = 'zzz.ru';
$_SERVER['REMOTE_ADDR'] = '127.0.0.1';
$_SERVER['REQUEST_METHOD'] = 'GET';
chdir('/home/zzz.ru/public_html/');
include_once
'./includes/bootstrap.inc';drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
drupal_cron_run(); ?>
и тогда при обновлении ничего не отпадет.
Я лишь показал что нужно поправить, если уж человек полез запускать непосредственно через php.
На счет телодвижений - в перспективе этот вариант требует таки меньше телодвижений. Например если у нас 1000 сайтов на одном drupal, то мы просто впишем сюда цикл, а не будем 1000 раз вызывать из crontab браузер (у некоторых хватит ума вписывать отдельной строкой. я видел по 30 таких вызовов...)
сам PHP на выполнение cron.php у меня жрет - 13,384,894 bytes allocated.
Мог бы, но он решил править файл из дистрибутива, который при обновлении будет изменён. И если он это понимает, не факт, что это поймёт новичок, последовавший его примеру.
...то крон будет наименьшей из ваших проблем...
Поэтому разговор о занимаемой памяти тоже особого смысла не имеет: 13мб на PHP да пару на lynx/wget - не существенно.
Первоначальный поиск не привел к результату, спасибо ребята за помощь, что еще раз показали то, что уже лежит в faq'е. Об обновлении я как-то не подумал, но файл действительно стоит переименовать, что я и сделал
Рябзя а кто-нить пробывал на 1Gb хостинге запустить в "CRON (исполнение скриптов по расписанию)" ?
Мне вот такое выдало "Ошибка HTTP запроса к site.ru/cron.php или запрос занял более 1 секунд"
Как правильно ссылку прописать, может в этом проблема?
только что проверил последний запуск был "Получен ответ (1 байт)" - это хорошо?:)
Вполне может быть. Крон отдаёт пустую страницу.
посмотрел отчеты в журнале системы все норм работает=)
Заработало таким образом
У меня cpanel
в админке в меню планировщик cron... прописал
Надо прописать
/usr/bin/wget -O - -q -t 1 http://*site_domen*/cron.php
В результате
/usr/bin/wget -O - -q -t 1 http://*site_domen*/cron.php >/dev/null 2>&1
( >/dev/null 2>&1 система сама добавляет)
При этом снизу в выпадающем меню - указываю каждый день или еще как...
Спасибо
В семёрке это из админки сайта делается. Кстати тема к 4-му относится.