настройка скрипта периодического запуска
Запуск скриптов по расписанию
Планирование однократного запуска скриптов с использованием команды at способно облегчить жизнь во многих ситуациях. Но как быть, если нужно, чтобы скрипт выполнялся в одно и то же время ежедневно, или раз в неделю, или раз в месяц?
В Linux имеется утилита crontab, позволяющая планировать запуск скриптов, которые нужно выполнять регулярно.
Crontab выполняется в фоне и, основываясь на данных в так называемых cron-таблицах, запускает задания по расписанию.
Для того, чтобы просмотреть существующую таблицу заданий cron, воспользуйтесь такой командой:
При планировании запуска скрипта по расписанию crontab принимает данные о том, когда нужно выполнить задание, в таком формате:
минута, час, день месяца, месяц, день недели.
Например, если надо, чтобы некий скрипт с именем command выполнялся ежедневно в 10:30, этому будет соответствовать такая запись в таблице заданий:
Здесь универсальный символ «*», использованный для полей, задающих день месяца, месяц и день недели, указывает на то, что cron должен выполнять команду каждый день каждого месяца в 10:30.
Если, например, надо, чтобы скрипт запускался в 4:30PM каждый понедельник, понадобится создать в таблице заданий такую запись:
Нумерация дней недели начинается с 0, 0 означает воскресенье, 6 — субботу.
Вот ещё один пример. Здесь команда будет выполняться в 12 часов дня в первый день каждого месяца.
Нумерация месяцев начинается с 1.
Затем можно вводить команды формирования расписания:
30 10 * * * /home/likegeeks/Desktop/myscript
Благодаря этой команде скрипт будет вызываться ежедневно в 10:30.
Если вы столкнётесь с ошибкой «Resource temporarily unavailable», выполните нижеприведённую команду с правами root-пользователя:
Организовать периодический запуск скриптов с использованием cron можно ещё проще, воспользовавшись несколькими специальными директориями:
Если поместить файл скрипта в одну из них, это приведёт, соответственно, к его ежечасному, ежедневному, еженедельному или ежемесячному запуску.
Запуск PHP скрипта по расписанию cron. Когда не всё так ясно
В этой статье я расскажу о некоторых тонкостях запуска php-скриптов на хостингах, незнание которых может попортить немало нервов и начинающим программистам, и мастерам средней руки.
Причина написания статьи: проблемы с запуском скриптов на хостингах с разными настройками. А поскольку настройки могут быть разными, информация приводимая для общих случаев могут не подходить и приводить в заблуждения.
Немного теории по этим ссылкам: тут и тут, для тех хочет освежить память.
Случай первый
В настройках операционной системы не указаны пути по умолчанию. Как следствие следующая команда в cron не будет выполнена.
Правильной командой будет второй вариант, где мы пропишем полный путь до интерпретатора php.
Есть ещё несколько способов запуска php скрипта описанных здесь. Интересным будет здесь то, что php скрипт запускается как файл с командами для консоли и тут можно написать целую тучу команд и описать всевозможные варианты на любой вкус. Код выглядит так.
В команде для выполнения в cron прописывается путь к скрипту и только. В скрипте ставятся символы #!, а дальше просто пишем нужные нам команды на языке bash.
Случай второй
Выполнение скрипта при запросе из браузера приводит к выводу страницы в браузер. А при выполнении скрипта через cron приводит к выводу текста страницы в командную строку. Тут может быть несколько вариантов. Система может быть настроена на сохранение результатов вывода в консоль в виде файла. Причем файл этот может размешаться не в самом типичном месте. Постепенно это может забить всё пространство на диске. Часто под сайт дают место в 1 Гигабайт, 500 мегабайт. И даже встречались хостинги с 50 и 10 мегабайт под сайт.
Как вариант, вывод может быть перенаправлен на почтовый ящик, который заботливый хостер ненавязчиво подарил вам и прописал в настройках хостинга как email по умолчанию. При каждом выполнении скрипта весь текст, выводящийся в консоль, будет оформлен в письмо. Проблемы могут начаться неожиданно. Если задание cron выполняется часто, а у почты хостинга прописано ограничение на количество писем в день, почта просто ляжет (заблокируется провайдером как потенциальный спамер). И как неприятные последствия вы получите отказ в регистрации пользователей, уведомление пользователей и д.р., что подвязано на почту.
Решение старо как мир. Нужно сделать перенаправление вывода из консоли в пустоту. Делается это добавлением команды в конце команды крона.
Иногда админы хостинга берут на себя обязанность ненавязчиво поставить их за пользователя. Тут тоже может быть подводный камень.
Случай третий
Ситуация проста. Нужно отладить скрипт, запускаемый планировщиком. Можно попытаться сделать это средствами php, заставлять скрипт писать логии и т.п. Но есть способ куда проще, нужно перенаправить вывод в файл. Команда проста, дополнительный параметр к нашей команде:
Её надо добавить в конце команды:
Знак «>» указывает системе о перенаправлении вывода. Далее имя файла. В нашем случае указан абсолютный путь. Этот пример не составляет труда найти в интернете. Но тут нас может поджидать неприятность, вытекающая из второго случая. Заботливый хостер автоматически добавляет перенаправление вывода в конце нашей строки. И иногда маскирует это. В итоге получается команда вида:
В итоге вывод снова перенаправлен в пустоту и выходной файл будет пуст. Тут хостеру можно указать на его ошибку, что он уж слишком перехитрил с настройками. А можно сразу воспользоваться костылём. После команды перенаправления в файл закончить команду символами &&. Эти два символа используются в командной строке для объединения нескольких команд в одной строке. Они дают командной строке понять, что команда окончена и дальше идет следующая команда. К ней и применяется перенаправление в пустоту. В итоге и перенаправление в пустоту осталось и лог файл записан верно. Пример команды:
Случай четвёртый
Первое, что находишь в интернете по этой проблеме – совет прописать в кроне команду смены директории:
Но в каких-то случаях это не помогает. Выход есть. Один из них взять всё в свои руки и задать недостающее окружение для работы скрипта. Информации про это в интернете уже больше.
Иногда просто хватает вписать следующий код в начале скрипта и пути снова становятся рабочими.
Как видите, всё прописано функциями и утруждаться настройками не надо.
Регулярное резервное копирование публичной части второго сайта с помощью cron
Понадобилось сегодня настроить регулярное резервное копирование двух сайтов на Битрикс с помощью задачи cron на сервере.
Например, на одном Битрикс, на одной админке настроена многосайтовость, два сайта:
Версия Битрикс 14.9.4, как оказалось, на этой версии Битрикс не делает бэкап публичной части сайта site2.ru, с первым проблем нет, может это косяк, не знаю, но времени разбираться некода, исправим это недоразумение.
Настройка регулярного резервного копирования в Битрикс
Делать регулярное резервное копирование сайтов на Битрикс будем так:
При такой настройке резервные копии будут создаваться отдельно для каждого сайта, размер их будет минимальный, вот так:
Хочу обратить внимание, что в моем случае для сайта site1.ru исключена из резервной копии папка /upload/, т.к. она размером почти 10Гб и бэкапить ее каждый раз нет смысла, этут папку будем ежедневно синхронизировать на локальном копьютере, поэтому размер полной резервной копии небольшой.
О синхронизации и бэкапах сайта на локальный компьютер я расскажу в следующий раз.
Вот так будет выглядеть форма настроек скрипта периодического запуска для site1.ru (полное резервное копирование сайта)
У Вас настройки должны быть точно такие, кроме раздела настроек Удаление старых копий, т.е. когда удалять старые резервные копии настройте как удобно в Вашем случае, можете оставить такими, не забудьте сохранить настройки.
Настройка на сервере задачи cron
Далее, на сервере в консоли или в панели управления сервером необходимо добавить задачу для cron, которая в указанное время будет запускать скрипт резервного копирования, в моем случае это панель vesta, в ней команды запуска скрипта выглядят так:
Обратите внимание на файлы резервного копирования, для сайта site1.ru я взял стандартный файл бэкапа Битрикс:
и переименовал в backup_site1.php, чтобы не запутаться в следующий раз, что куда бекапит, это стандартный скрипт backup.php.
А вот для сайта site2.ru мне нужно бэкапить только его публичную часть, если посмотрите на форму настроек бэкапа Битрикс выше, то там нет возможности отключить для второго сайта бэкап БД, ядра и т.д.
Для этого я скопировал опять срипт бэкапа backup.php и переименовал в backup_site2.php, далее настроил под себя:
В файле необходимо задать префикс сайта, чтобы повлиять на имя архива.
Это условие сработает, если не установлены модули bitrixcloud и clouds, я их всегда удаляю, т.к. они не используюся на всех моих сайтах и сайтах клиентов, иначе сработают условия выше, но там название архива будет состоять из даты, должно сработать правильно.
Ну и задать настройки бэкапа вручную осталось, т.к. скрипт backup.php берет настройки из формы на сайте, все настройки в массиве $arExpertBackupDefaultParams, такие:
Все готово, теперь и многосайтовость при регулярном резервном копировании будет учтена, резервные копии будут по полочкам в наименьшем виде:
О синхронизации бэкапов и самой большой папки сайта /upload/ на свой ПК я расскажу Вам чуть позже, там даже все сайты сможете на локальный ПК синхронизировать и бэкапить, инструменты сейчас есть для этого хорошие.
Прикрепил готовый скрипт резервного копирования с комментариями, где и что изменить, достаточно в одном месте задать префикс для свогео сайта и все.
Фоновое выполнение скрипта на PHP без crontab
Озадачили меня тут написать демона на PHP. Т.е. скрипт, который будет заданное количество раз в заданное количество часов в случайное время (всегда случайное) выполнять определенные действия, и все это без использования cron’a.
До этого никогда не заморачивался, а тут после постановки задачи, начал было думать что так нельзя, что php скрипт надо вызывать браузером…ну задача то поставлена, надо выполнять.
Первая мысль — отключить ограничение времени выполнения скрипта. Запрещено хостером.
Вторая мысль — яваскриптом повторять аякс-запрос периодически (да хоть раз в секунду). — нельзя (требование заказчика).
Выяснилось, собственно, что и браузер открыт не должен быть, и крон нельзя использовать, и работать скрипт должен независимо от пользователя, бесконечно долго. Естественно, он должен минимум грузить систему.
1. Пачка сигарет, ночь, гугл, доки, книги, мануалы….
goto 1…
На выходе получаю:
Задача_1:
Реализовать генератор времен выполнения скрипта, исходя из заданных количества раз и количества часов. Хранить где-то эти времена.
Задача_2:
Работать после закрытия браузера
Задача_3:
Не вылетать после окончания ограничения времени выполнения скрипта
Задача_4:
Выполнять в нужное время какие-то действия.
Итак…
Пишем в конфиге исходные данные:
Далее пишем функцию, которая поможет нам сгенерировать времена запуска.
В ней мы генерируем случайное число от 0 до количества секунд в исходном интервале.
Далее сгенерируем и запишем в сессию массив времен запуска. Предварительно отсортируем массив по возрастанию, чтобы сначала шло раннее время (машину времени я еще не успел создать).
Теперь надо заставить скрипт работать, не обращая внимания на максимальное время выполнения, установленное сервером.
Принцип таков:
1) Определяем время начала работы скрипта;
2) Определяем установленное ограничение на время выполнения.
3) Запускаем цикл, внутри которого считаем текущее время и вычисляем общее время работы скрипта, сверяем текущее время со значениями в массиве времен запуска, и если совпадение есть, выполняем заданные действия (у меня они в файле exec.php). Для запуска файлов используем сокеты.
4) Повторяем цикл пока время работы скрипта не приблизится к максимально разрешенному. Я поставил — пока до максимального времени не останется 5 секунд.
Итак… считаем начальные данные по времени:
Собственно, цикл. Комментарии в коде.
Ну и, если разрешенное время подходит к концу, то завершаем цикл и благополучно запускаем этот же скрипт другие процессом (в 5 секунд точно уложимся)
Собственно, готово.
Далее у меня много заморочек было в выполнении тех самых действий — там надо было робота написать для поиска ссылок по заданным ссылкам.
Когда дописал все, озадачился полезным применением…Использовать его можно как службу. Он может следить за чем-то в сети и уведомлять Вас, например, по почте. И не надо никаких cron’ов.
Скрипт можно еще оптимизировать — доработкой не занимался.
Кстати, вот от чего я не смог оторваться — браузер все же придется открыть, чтобы изначально запустить скрипт.
Автоматическое резервное копирование в облако битрикс
С версии 12.0.8 появилась возможность создавать резервную копию сайта и выгружать её в облако 1С-Битрикс в автоматическом режиме. На партнерской конференции у меня был доклад на эту тему. Сейчас постараюсь осветить важные моменты на основе материалов доклада.
[spoiler]
Мы говорили раньше, что нельзя сделать автоматическую резервную копию на агентах. В этом смысле ни мы, ни мир не изменились: автоматическая резервная копия создается не на хитах, а на cron ‘е. Т.е. посетители сайта не ощущают замедления загрузки страниц, а бэкап получается целостный.
Зачем мне надо облачное хранилище 1С-Битрикс?
Когда бэкап сайта хранится снаружи, возникает вопрос безопасности. Мы его очень хорошо продумали, о чем иллюстрация ниже.
Это безопасно! Созданный архив шифруется с использованием современных алгоритмов шифрования на основе вашего секретного слова. При буквенно-символьном пароле длиною более 8 символов перебор его займет десятки (а может и сотни) лет!
Но это еще не всё. В нашем облаке хранится хеш от пароля для того чтобы проверить пароль еще перед отдачей шифрованного архива. Таким образом, возможность перебора пароля исключается еще до получения архива. Хеш, который хранится у нас, позволяет проверить пароль, но не позволяет расшифровать архив. Это значит, что никто внутри нашей компании не сможет получить доступ к вашим данным.
Таким образом, чтобы узнать пароль резервной копии, нужно иметь доступ к базе данных и файлам, т.е. теряется целесообразность его получения.
Это удобно! Вы можете из любого места выгрузить бэкап в облако: неважно, хостинг это, локальная сеть или персональный компьютер, развернуть копию сайта в любом месте очень просто. Мы и сами используем облако для переезда с Битрикс24 на коробку: клиенту в итоге нужен только пароль архива, который потом разворачивается через restore.php и своего лицензионного ключа.
Это просто! Мы всё сделали для того, чтобы пользователь не загружался технологическими трудностями: всё делается в несколько кликов из админки, даже настройка бэкапа по расписанию. Чуть ниже опишу это подробнее.
Честно сказать, я не вижу причин не использовать это. Разве только незнание такой возможности. Игнорировать её просто неразумно!
Как настроить автоматическое резервное копирование
Если системные агенты выполняются на cron (а это уже настроено в нашей виртуальной машине ), то никакие дополнительные настройки на хостинге не нужны.
И выбираем время:
В случае ошибки повторный запуск будет только через сутки. Это сделано для того чтобы не переполнить диск и не парализовать работу сайта в следствие нагрузки. Текст ошибки попадет в журнал событий, а в случае системного сбоя надо смотреть журнал cron’а.
Если агенты выполняются на хитах, возможности выбрать время нет, о чем подскажет сноска 1 :
Тогда можно либо настроить их на cron (не вижу причин этого не делать), либо безусловно запустить через cron скрипт /bitrix/modules/main/tools/backup.php
в нужное время.
Вы можете делать резервную копию не только в наше облако, но в любое другое, которое настроено вручную. А также просто складывать на диск.
По сравнению с ручным режимом тут есть дополнительные опции очистки старых локальных копий по одному из условий:
Удаление после успешной передачи в облако происходит в ручном режиме, а теперь вы можете иметь некоторое число локальных копий для быстрого доступа к ним и три последних копии в надежном облачном хранилище. При этом учитывается тот факт, что резервная копия может состоять из нескольких файлов, они рассматриваются как один архив.
На момент анонса этой возможности на конференции месяц назад в облаке 1С-Битрикс было 2800 резервных копий объёмом 1,7 Тб. Сегодня в облако выгружено 3900 копий объемом 2,5 Тб. Но это очень мало по отношению к числу активных лицензий.
Создавайте резервные копии до того, как они потребовались, иначе будет слишком поздно!