Не каждый сайт живёт на своём сервере. Часть наших проектов работает на виртуальном хостинге, и там свои правила: панель вместо crontab, консоль со старым PHP, защита от ботов, которая мешает проверкам. Настройка одной задачи крона на таком хостинге заняла три захода — вот что мы на них узнали.

Это 12-я часть цикла «Сервер для WordPress». Речь об одном конкретном хостинге, но устроены похоже многие.

Планировщик: «Минуты: 1» — это раз в час

Поля планировщика в панели — обычные поля crontab, и цифра означает «ровно в этот момент», а не «каждые столько».

Что ввелиЧто получилось
Минуты: 1, остальное *раз в час, на первой минуте
все пять полей *раз в минуту
Минуты: */10раз в 10 минут

Адрес — не команда

В поле команды хочется вписать адрес https://site.ru/wp-cron.php. Планировщик выполняет строку в оболочке, и получается command not found. Ошибку хостинг присылает письмом на почту аккаунта — оттуда и узнали.

# без HTTP — надёжнее: мимо редиректов и защиты от ботов
/usr/local/bin/php8.2 ~/site.ru/public_html/wp-cron.php

# через HTTP — с самой командой curl и адресом в кавычках (из-за ? и =)
/usr/bin/curl -s -o /dev/null "https://site.ru/wp-cron.php?doing_wp_cron=1"

Тильда в пути раскрывается. А вот посмотреть задачи из консоли нельзя: crontab -l по SSH недоступен, задачи живут только в панели. Работает ли задача — проверяйте по следствию: обновилась ли отметка последнего запуска в самом приложении.

PHP в консоли — 5.6

Команда php в консоли хостинга запускает PHP 5.6. Современный код на нём не разбирается, и скрипт молча ничего не делает. Версии лежат рядом, вызывать нужную явно: /usr/local/bin/php8.2. Версию, на которой работает сам сайт, видно в заголовке X-Powered-By или в панели.

Защита от ботов на POST

POST-запрос от незнакомого клиента — например, проверка ajax-адреса через curl — получает не ответ сайта, а страницу со скриптом, которая ставит куку и перезагружается. Для проверок кука подставляется явно:

curl -s -X POST "https://site.ru/wp-admin/admin-ajax.php" \
  -b "beget=begetok" -A "Mozilla/5.0" -d "action=..."

GET-запросы проходят без неё.

Дамп базы с ошибкой, которая не ошибка

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s)
for this operation' when trying to dump tablespaces

Дамп при этом делается полностью. Проверять не по этой строке, а по целостности архива (gzip -t) и по строке -- Dump completed в конце файла.

Реквизиты базы для дампа удобнее достать из wp-config.php текстом, а не подключать его в скрипт: в конце он загружает весь WordPress.

DB_NAME=$(sed -n "s/^ *define( *'DB_NAME' *, *['\"]\([^'\"]*\)['\"].*/\1/p" wp-config.php)

Время — московское

Сервер хостинга живёт по Москве, а не по UTC. Прибавлять три часа «для перевода» не нужно — это уже Москва. Проверять date и date -u рядом, прежде чем ставить задачу «на 3 ночи».

Ещё ограничения

  • журналы nginx по SSH не отдаются — только в панели;
  • сборка фронта на виртуальном хостинге может не уложиться в память — собирать лучше у себя и выкладывать готовое.

Задачи по расписанию на хостинге «не срабатывают»?

Пришлите, что настроено в панели, — найду, почему крон молчит.

· полезно?
АЧ
Алексей Чикун веб-разработчик, команда TRIOHEAD

Делаю сайты и сервисы целиком: от вёрстки до сервера. Пишу о том, что проверил на своих проектах.

Комментарии

// загружаю комментарии…

Комментарии публикуются после проверки. Ссылки и HTML не принимаются.