2. Откройте этот файл и запишите в него дату, время и нужную информацию по данному событию средствами php.
3. Закройте файл средствами php.
4. Ждите запуска крона.
5. Любуйтесь информацией в этом файле. Если файл пуст, то либо накосячили в первый двух пунктах, либо событие по крону не запустилось. Косяки первый двух пунктов можно увидеть запустив крон вручную.
крон имеет тенденцию не выполняться
такого не бывает. крон может не выполниться из-за ошибки, прописывайте правильно, если брать php-скрипты, то обязательно переход в директорию скрипта, а именно:
если нужно проверить крон, то настраиваем вывод
в этой команде крону указывается переход в папку и затем выполнение необходимого скрипта
прописывайте правильно, если брать php-скрипты, то обязательно переход в директорию скрипта,
Не вводите людей в заблуждение, интерпретатору php можно указать, например, полный путь к исполняемому скрипту.
интерпретатору php можно указать, например, полный путь к исполняемому скрипту
нет, нельзя, т.к. это разные уровни запуска скрипта, и мы не про интерпретатор а про CRON
например: php -f /site.domen/papka/cron.php это глобальный вызов скрипта от текущего пользователя, на многих серверах крон не запустит этот скрипт
cd ~/домен/папкасайта/ && php cron.php > /dev/null 2>&1
это локальный запуск скрипта в рамках текущей папки/сайта, и работает абсолютно везде, на серверах с любым уровнем настроек безопасности и изоляции процессов
Dublic, вы в данный момент уже не только со мной спорите, но и с документацией
вы в данный момент уже не только со мной спорите, но и с документацией
Судя по вашему профилю, вы зарегистрированы на этом сайте 3 года назад. Тому, что указано в документации по CRON уже 10 лет. Т.е. это не корректные данные по CRON (дезинформация), работа ядра Linux значительно изменилась, крон вынесен в отдельный процесс зависящий от SystemD
Ради интереса сейчас проверил. У меня три сервера и ни на одном эта 👇 команда CRON не выполняется
один сервер на VestaCP, другой в облаке хостера с их панелью, третий с панелькой FastPanel, на всех трёх крон не может запустить скрипт таким образом 👆
а вот так 👇, скрипт корректно запускается на всех трех серверах
такой метод запуска php-скриптов по крон я использую уже минимум 4 года
Судя по вашему профилю, вы зарегистрированы на этом сайте 3 года назад
И что?
Тому, что указано в документации по CRON уже 10 лет. Т.е. это не корректные данные по CRON (дезинформация), работа ядра Linux значительно изменилась, крон вынесен в отдельный процесс зависящий от SystemD
Вы это Fuze сообщите.
А внизу той странички документации написано
manual/settings/scheduler.txt · Последнее изменение: 10.09.2019 16:10 — fuze
Вы это Fuze сообщите
либо Fuze в линукс не разбирается, либо «болт» положен на безопасность сервера. Или настройки указаны исключительно в рамках сервера (хостинга) который используют разработчики instantCMS
вы не переживайте, сегодня я внесу изменения на рассмотрение по команде крон в гитхаб для версии instantCMS 2.15
вы не переживайте, сегодня я внесу изменения на рассмотрение по команде крон в гитхаб для версии instantCMS 2.15
Ссылку потом сюда положите, пожалуйста.
Ссылку потом сюда положите, пожалуйста.
Вот ссылка на правку на гитхабе github.com/instantsoft/icms2/pull/1340
нет, нельзя, т.к. это разные уровни запуска скрипта, и мы не про интерпретатор а про CRON
на многих серверах крон не запустит этот скрипт
либо Fuze в линукс не разбирается, либо «болт» положен на безопасность сервера.
Я не знаю, про что вы) Безопасность сервера тут не при чем. Не запуститься может по одной причине: если указан не полный путь к PHP интерпретатору. /usr/bin/php или иной верный полный путь решит проблему. В документации указан принцип и какой файл указывать для запуска, т.е. просто рекомендации. Внесу туда полный путь к PHP. Кроме этого, не запускаться может потому, что при запуске задачи CRON переменные окружения (пути к /bin, /usr/bin и т.п.) не обозначены. Обычно в файле команд CRON делают финт ушами и обозначают их там.
Но я ни разу не сталкивался с проблемой запуска задачи CRON.
И да, с серверами Linux я работаю 15 лет 🙂
я внесу изменения на рассмотрение по команде крон
На гит то зачем?
На гит то зачем?
дак чтоб во время инсталляции команда уже была корректна. Это более универсальная команда:
а эта 👇 команда «специфична» к настройкам сервера
ПОЧЕМУ?
Как минимум потому, что мы не в кроне определяем где находится интерпретатор и какой именно версии, а в настройках окружения и/или вебсервере. Поэтому, в кроне мы просто пишем в какую папку перейти и какой скрипт запустить, всё остальное мы настраиваем в других местах (окружение и веб-сервер)
И да, с серверами Linux я работаю 15 лет
я чуток поменьше — 13 лет, но данном «линукс-возрасте» разница в деталях «кто где/куда копал и что и как использовал»
Я не знаю, про что вы) Безопасность сервера тут не при чем
Вы упустили: Или настройки указаны исключительно в рамках сервера (хостинга) который используют разработчики instantCMS 😉
Я не знаю, про что вы
чуток подумав как объяснить, решил дополнить. Через крон наш скрипт запускается через php-cli. Но php-cli у нас на разных уровнях разный, есть уровень сервера, есть уровень приложения. Команда php -f /path/to/site/cron.php запускает php-cli на уровне всего сервера от текущего пользователя, т.к. крон работает только глобально на весь сервер и никак иначе. Команда cd ~/path/to/site/ && php cron.php запускает php-cli на уровне приложения от текущего пользователя
и снова дополню, чтоб уже наверняка. Первая команда php -f /path/to/site/cron.php говорит крону " — выполни вот этот файл" и он выполняет исходят из глобальных настроек юзера. Вторая команда cd ~/path/to/site/ && php cron.php говорит крону "- выполни этот файл в той-то директории"
под одним юзером у нас могут быть разные версии и настройки php для каждого отдельного хоста, поэтому и выполнение по крон должно привязываться к конкретным директориям, а не к юзеру