Как проверить работу php на компьютере
Обновлено: 06.07.2024
У меня есть cron-скрипт, который выполняет PHP-скрипт каждые 10 минут. Скрипт проверяет очередь и обрабатывает данные в очереди. Иногда очередь имеет достаточно данных, чтобы длиться более 10 минут обработки, создавая потенциал двух сценариев, пытающихся получить доступ к одним и тем же данным. Я хочу иметь возможность определить, запущен ли скрипт, чтобы предотвратить запуск нескольких копий скрипта. Я думал о создании флага базы данных, который говорит, что скрипт обрабатывает, но если сценарий должен был когда-либо рухнуть, он оставил бы его в положительном состоянии. Есть ли простой способ узнать, работает ли PHP-скрипт уже из PHP или shell-скрипта?
Если вам нужно, чтобы он был абсолютно устойчив к сбоям, вы должны использовать семафоры, которые освобождаются автоматически, когда php завершает обработку конкретного запроса.
более простым подходом было бы создать запись БД или файл в начале выполнения и удалить его в конце. Вы всегда можете проверить "возраст" этой записи/файла, и если он старше, чем, скажем, в 3 раза больше обычного выполнения скрипта, предположим, что он разбился и удалил его.
нет "серебряная пуля", это просто зависит от ваших потребностей.
вы можете просто использовать файл блокировки. PHP flock() функция обеспечивает простую оболочку для Unix flock функция, которая обеспечивает консультативные блокировки файлов.
Если вы явно не отпустите их, ОС автоматически освободит эти блокировки для вас, когда процесс, удерживающий их, завершится, даже если он завершится ненормально.
вы также можете следовать свободной конвенции Unix о том, чтобы сделать ваш файл блокировки "PID-файлом" - то есть получив блокировку файла, ваш скрипт запишет в него свой PID. Даже если вы никогда не читали это из своего скрипта, вам будет удобно, если ваш скрипт когда-либо зависнет или сойдет с ума, и вы хотите найти его PID, чтобы вручную убить его.
вот копия / вставка-готовая реализация:
просто установите путь к файлу блокировки, где вам нравится, и вы настроены.
Если вы используете Linux, это должно работать в верхней части вашего скрипта:
обычный способ для демонов *nix (хотя и не обязательно PHP-скрипты, но он будет работать) - использовать a .пид файл.
при запуске скрипта проверьте наличие a .PID-файл, названный для скрипта (обычно хранится в /var/run/). Если он не существует, создайте его, установив его содержимое в PID процесса, выполняющего скрипт (используя getmypid) затем продолжить нормальное выполнение. Если он существует, прочитайте PID из него и посмотрите, работает ли этот процесс, вероятно, бегом ps $pid . Если он работает, выходите. В противном случае перезапишите его содержимое своим PID (как указано выше) и продолжите обычное выполнение.
по завершении выполнения удалите файл.
Я знаю, что это старый вопрос, но если кто-то еще ищет здесь, я отправлю некоторый код. Это то, что я сделал недавно в подобной ситуации, и это работает хорошо. Поместите этот код в верхнюю часть файла, и если тот же скрипт уже запущен, он оставит его и завершит новый.
Я использую его, чтобы постоянно поддерживать систему мониторинга. Задание cron запускает сценарий каждые 5 минут, но если другой не остановился по какой-либо причине (обычно, если он разбился, что очень редко!) Новый просто выйдет сам.
Он не будет работать без изменений в Windows, но должен быть в порядке в системах на базе unix.
вы можете использовать new Symfony 2.6 LockHandler
это работает для меня. Установите запись базы данных с флагом блокировки и отметкой времени. Мой скрипт должен завершиться хорошо в течение 15мин, поэтому добавил, что в качестве последнего заблокированного feild проверить:
затем разблокируйте его в конце скрипта:
Я пробовал это. Хорошо работает и в Windows.
спасибо @martinodf за его идею.
Я знаю, что это старый вопрос, но есть подход, который не упоминался ранее, который, я думаю, стоит рассмотреть.
одна из проблем с решением lockfile или Database flag, как уже упоминалось, заключается в том, что если сценарий завершится неудачей по какой-либо причине, отличной от обычного завершения, он не освободит блокировку. И поэтому следующий экземпляр не запустится, пока блокировка не будет очищена вручную или очищена функцией очистки.
Если, однако, вы конечно, сценарий должен выполняться только один раз, тогда относительно легко проверить из сценария, работает ли он уже при запуске. Вот код:
просто вызовите эту функцию в начале скрипта, прежде чем делать что - либо еще (например, открыть обработчик базы данных или обработать файл импорта), и если тот же скрипт уже запущен, он появится дважды в списке процессов-один раз для предыдущего экземпляра и один раз для этого. Так что, если он появится более одного раза, просто выйдите.
потенциальный gotcha здесь: я предполагаю, что у вас никогда не будет двух скриптов с одинаковым базовым именем, которые могут законно работать одновременно (например, тот же скрипт, работающий под двумя разными пользователями). Если это возможно, вам нужно расширить проверку на что-то более сложное, чем простая подстрока в базовом имени файла. Но это работает достаточно хорошо, если у вас есть уникальные имена для ваших скриптов.
Многие начинающие вебмастера рано или поздно начинают задумываться над вопросом: Как же проверить работоспособность своего сайта на локальном компьютере? Конечно если странички сайта сделаны на чистом html, то и вопросов не возникает. Обычно люди просто открывают html фалы через интернет-браузер и страница сайта отображается так же, как и на сервере. Но когда начинающие вебмастера, уже освоив html, делают свои первые шаги в изучении такого языка веб-программирования: как php, то появляются проблемы.
Php страницы сайта на локальном компьютере не работают так же как на сервере. В отличии от html, php для компьютера уже не просто интернет-страничка, а скрипт написанный на языке php.
В начале своего пути: освоения веб-программирования. Я практически сразу же познакомился с этой замечательной программой, просто случайно наткнулся в интернете. И сейчас, я уже не представляю свою дальнейшую работу с сайтами без Denwerа.
Денвером можно пользоваться совершенно бесплатно, но за такую программу, если бы она была платная, не жалко было бы и заплатить.Для установки программы надо запустить установщик и следовать инструкции которая появится у Вас на экране. Denwer создаст папку: WebServers в в корне диска С . А так же создаст виртуальный диск на Вашем компьютере, и присвоит ему последнюю букву диска, как привило – Z . На диске Z будут находится файлы идентичные файлам находящимся в папке: C:\WebServers . На Вашем рабочем столе появятся три ярлыка созданные программой: Запуск программы, перезагрузка денвера и остановить программу.
И теперь, чтобы тестировать сайт на своем компьютере достаточно запустить программу. Все файлы и папки тестируемых сайтов должны находиться по адресу: C:\WebServers\home\localhost\www . То есть, в директории: www, Вам надо создать папку и закинуть в неё все файлы Вашего тестируемого сайта.
Только делайте почаще, на всякий пожарный, резервную копию директории: C:\WebServers . У меня один раз, денвер отказался работать и эта папка куда то исчезла. Хорошо что была резервная копия 8) .
Это статья не про юнит-тесты и вообще не про тестирование. Это про то, как выполнить фрагмент кода на языке программирования, если под рукой нет компьютера с нужным интерпретатором. Если есть браузер, то интерпретатор javascript, конечно, под рукой, вот только создание идеального тестового окружения займёт некоторое время. А представь, что на это время тратить не надо? Скопипастил код, запустил, посмотрел результат. И так же можно быстро прогнать алгоритм на других языках. Я чаще всего я применяю такие онлайн-ресурсы для тестирования скриптов для составления тестовых заданий на собеседования и для быстрой проверки своих решений на вопросы с stackoverflow или hashcode.
Проверка кода PHP online
Очень большой выбор языков программирования и библиотек.
онлайн-компилятор и интерпретатор скриптов
Среди языков: C, C++, D, Haskell, Lua, OCaml, PHP, Perl, Python, Ruby, Scheme, Tcl. Я не проверял, на всех ли языках работает интерпретация или компиляция.
Отладка скриптов PHP Python Ruby
Позволяет выбрать версию интерпретатора PHP и поделиться кодом.
Run PHP script on PHP4 PHP5
Аналогичные возможности: запуск скрипта PHP в браузере с использованием разных версий интерпретатора PHP и возможность поделиться кодом.
Test PHP code online, run PHP script in browser
Очень сложное решение, позволяющая подключить к интерпретатору PHP большой список модулей расширения.
PHP, MySQL, HTML, CSS, JS IDE and online execution environment
Execute PHP Algorithm, Run PHP Algorithm
онлайн-компилятор и интерпретатор скриптов PHP
Execute PHP Script Online
Тестирование скрипта Python
Посмотри на CodePad и Ideone, описанные выше.
Также можно зайти на страницы учебных курсов по Python и протестировать свой алгоритм в консоли:
Запуск скриптов Ruby в браузере
Посмотри на CodePad и Ideone, описанные выше.
Также можно зайти на страницы учебных курсов по Ruby и протестировать свой алгоритм в консоли
Отладка программы JavaScript
Один из самых популярных инструментов для работы с JavaScript/HTML/CSS/SCSS. Прост, удобен, умеет подключать дополнительные библиотеки: jQuery, MooTools и т.д.
Инструмент для фронт-энд разработки, позволяющий легко оперировать с CSS/HTML/JS-конструкциями, позволяет подключать js-библиотеки: jQuery, MooTools и т.д.
Уже более 15 лет занимаюсь разработкой веб-проектов. Fullstack Senior Developer. IT евангелист — доношу свет знаний об информационных технологиях. Профессиональные цели: Дать людям возможность дать людям больше.
Вопрос: Придумай несколько вопросов для телефонного собеседования по PHP для Senior Developer
Автор: Павел Волынцев · Published 21.02.2019 · Last modified 22.02.2019
Yii : работаем с PostgreSql и несколькими схемами
Автор: Павел Волынцев · Published 09.10.2013 · Last modified 07.09.2014
Yii : работа с базами данных
Автор: Павел Волынцев · Published 09.10.2013 · Last modified 23.04.2017
О, отлично. Совсем новый, похоже, сделан аккуратно, но глючный ещё.
Спасибо. Надо порядок тут в статье навести, картинки порядочные вставить
Повторная проверка проектов нередко бывает весьма интересной. Она позволяет узнать, какие новые ошибки были допущены в ходе разработке приложения, а какие ошибки уже были исправлены. Раньше мой коллега уже писал о проверке PHP. С выходом новой версии (PHP7), я решил ещё раз проверить исходный код интерпретатора и нашёл кое-что интересное.
Проверяемый проект
PHP — скриптовый язык общего назначения, интенсивно применяемый для разработки веб-приложений. Язык и его интерпретатор разрабатываются в рамках проекта с открытым кодом.
3 декабря 2015 года было объявлено о выходе PHP версии 7.0.0. Новая версия основывается на экспериментальной ветке PHP, которая изначально называлась phpng (Следующее поколение PHP), и разрабатывалась с упором на увеличение производительности и уменьшение потребления памяти.
Объектом проверки стал интерпретатор PHP, исходный код которого доступен в репозитории на GitHub. Проверяемая ветвь — master.
В качестве инструмента анализа использовался статический анализатор кода PVS-Studio. Для проверки использовалась система мониторинга компиляции, позволяющая осуществлять анализ проекта независимо от того, какая система используется для сборки этого проекта. Пробная версия анализатора доступна для загрузки по ссылке.
С предыдущей проверкой проекта можно познакомиться в статье Святослава Размыслова "Заметка про проверку PHP".
Найденные ошибки
Стоит отметить, что многие ошибки, найденные анализатором, находятся в библиотеках, используемых в PHP. Если все их рассматривать в этой статье, её объем бы порядочно вырос. Но с другой стороны ошибки, допущенные в библиотеках, используемых в проекте, проявят себя и при использовании проекта. Поэтому некоторые из этих ошибок всё же будут выписаны в этой статье.
Отдельно хотелось бы отметить, что во время анализа сложилось впечатление, что код целиком написан на макросах. Они просто повсюду. Это сильно усложняет задачу анализа, про отладку подобного кода я вообще молчу. Их повсеместное использование, к слову, вышло же боком – ошибки из макросов растаскивались по коду. Но об этом ниже.
Предупреждение PVS-Studio: V506 Pointer to local variable 'tmp' is stored outside the scope of this variable. Such a pointer will become invalid. spl_fixedarray.c 420
При истинности условного выражения оператора if, приведённого выше, указателю offset может быть присвоен адрес переменной tmp. При этом время жизни переменной tmp ограничено её областью видимости, т.е. телом оператора if. Но ниже по коду вызывается функция, принимающая в качестве одного из параметров указатель offset, который ссылается на уже уничтоженную переменную, что может привести к ошибке при работе с данным указателем.
Другой странный код:
Предупреждение PVS-Studio: V547 Expression is always false. Unsigned type value is never < 0. spl_directory.c 2886
Логика кода проста — сначала сравнивают 2 величины и берут из них меньшую, после чего полученный результат сравнивают с нулём и записывают в переменную str_len большее из этих значений. Проблема кроется в том, что size_t — беззнаковый тип, следовательно, его значение всегда неотрицательно. В итоге использование второго макроса MAX попросту не имеет смысла. Что это — просто лишняя операция, или какая-то более серьёзная ошибка — судить разработчику, писавшему код.
Это не единственное странное сравнение, встретились и другие.
Предупреждение PVS-Studio: V605 Consider verifying the expression: ub_wrote > — 1. An unsigned value is compared to the number -1. php_cli.c 307
Переменная ub_wrote имеет тип size_t, являющийся беззнаковым. Однако ниже выполняется проверка вида ub_wrote > -1. На первый взгляд может показаться, что это выражение всегда будет истинным, так как ub_wrote может хранить в себе только неотрицательные значения. На самом деле всё обстоит интереснее.
Тип литерала -1 (int) будет преобразован к типу переменной ub_wrote (size_t), то есть в сравнении ub_wrote с переменной будет участвовать преобразованное значение. В 32-битной программе это будет беззнаковое значение 0xFFFFFFFF, а в 64-битной – 0xFFFFFFFFFFFFFFFF. Таким образом, переменная ub_wrote будет сравниваться с максимальным значением типа unsigned long. В итоге результатом этого сравнения всегда будет значение false, и оператор return никогда не выполнится.
Следующий код, на который анализатор выдал предупреждение, также связан с макросом.
Предупреждение PVS-Studio: V571 Recurring check. The 'if (!sapi_module.phpinfo_as_text)' condition was already verified in line 975. info.c 978
На первый взгляд может показаться, что всё нормально, и ошибки нет. Но давайте взглянем на то, что из себя представляет макрос SECTION.
В итоге, после препроцессирования в *.i-файле будет содержаться код следующего вида:
Сейчас проблему заметить стало куда проще. Проверяется некоторое условие (!sapi_module.phpinfo_as_text) и, если оно не выполняется, опять проверяется это условие (которое, естественно, никогда не выполнится). Согласитесь, выглядит, как минимум, странно.
Схожая ситуация, связанная с использованием этого макроса, встретилась ещё раз в этой же функции:
Предупреждение PVS-Studio: V571 Recurring check. The 'if (!sapi_module.phpinfo_as_text)' condition was already verified in line 1058. info.c 1059
Аналогичная ситуация. То же условие, тот же макрос. Раскрываем, получаем код следующего вида:
Опять дважды проверяется одно и то же условие. Второе будет проверяться только в случае, если истинно первое. Тогда, если истинно первое условие (!sapi_module.phpinfo_as_text), то всегда будет истинным и второе условие. В таком случае код, находящийся в ветви else второго оператора if, не будет выполнен вообще никогда.
Предупреждение PVS-Studio: V590 Consider inspecting the '* walk == 0 || * walk != '>'' expression. The expression is excessive or contains a misprint. php_pcre.c 1033
В данном коде указатель разыменовывается, и его значение сравнивается с некоторыми литералами. Данный код избыточен. Для наглядности перепишем, упростив, выражение:
Как видите, условие можно упростить до a != 125.
Это может свидетельствовать как об избыточности кода, так и о том, что программист допустил более серьёзную ошибку.
Источником некоторых проблемных мест стал фреймворк Zend:
Предупреждение PVS-Studio: V610 Unspecified behavior. Check the shift operator '>>'. The left operand '(- 1)' is negative. zend_alloc.c 1865
В данном коде используется операция правостороннего битового сдвига отрицательного значения. Это случай неуточнённого поведения (unspecified behavior). Хоть с точки зрения языка такой случай и не является ошибочным, в отличии от неопределённого поведения, лучше избегать подобных случаев, так как поведение подобного кода может различаться в зависимости от платформы и компилятора.
Предупреждение PVS-Studio: V501 There are identical sub-expressions '(1 << ucp_gbL)' to the left and to the right of the '|' operator. pcre_tables.c 161
Об этой ошибке, кстати, писал ещё мой коллега в предыдущей статье, но воз и ныне там.
Другое место из той же библиотеки:
Предупреждение PVS-Studio: V519 The 'firstchar' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 8163, 8164. pcre_compile.c 8164
Согласитесь, код выглядит странно. Записываем результат операции '|' в переменную firstchar, и тут же перезаписываем её значение, игнорируя результат предыдущей операции. Возможно, во втором случае вместо firstchar подразумевалась другая переменная, но сказать наверняка сложно.
Встретились и избыточные условия. Например:
Предупреждение PVS-Studio: V728 An excessive check can be simplified. The '||' operator is surrounded by opposite expressions '!path' and 'path'. plain_wrapper.c 1487
Данное выражение является избыточным: во втором подвыражении можно убрать проверку указателя path на неравенство nullptr. Тогда упрощённое выражение примет следующий вид:
- V728 An excessive check can be simplified. The '||' operator is surrounded by opposite expressions '!path' and 'path'. fopen_wrappers.c 643
- V728 An excessive check can be simplified. The '||' operator is surrounded by opposite expressions '!headers_lc' and 'headers_lc'. sendmail.c 728
О сторонних библиотеках
Об этом я писал выше, но хочу повториться ещё раз. PHP использует некоторые сторонние библиотеки, которые, увы, не идеальны и содержат ошибки. Многие предупреждения выдавались как раз на код этих библиотек. Можно было бы проанализировать их все, но тогда, поверьте, статья вышла бы очень большой.
Определить, находится ли ошибка в коде интерпретатора PHP или сторонней библиотеки достаточно просто – в начале всех исходных файлов находится комментарий, описывающий лицензию, проект, авторов и пр. Отталкиваясь от этих комментариев легко определить, в файле какого проекта притаилась ошибка.
С другой стороны — некоторые интересные места всё же рассмотреть стоило. В любом случае, если вы используете какие-то сторонние библиотеки, ответственность перед пользователями за ошибки, допущенные в этих библиотеках, ложится также и на ваши плечи, так как ошибка может проявить себя в ходе использования именно вашего продукта. Поэтому стоит внимательнее относиться к тому, какие зависимости вы тянете в своём проекте.
Заключение
Результаты проверки вышли интересными. На самом деле нашлось много ошибок, в статье рассматривалась только малая часть общих предупреждений высокого и среднего уровней достоверности. Многие из этих ошибок находятся в библиотеках, которые используются в PHP, а значит, неявно, кочуют в его код. В самом коде PHP тоже обнаружились интересные ошибки, некоторые из которых и были выписаны выше.
Подводя итог, хотелось бы сказать, что необходимо использовать различные средства, позволяющие повысить продуктивность работы и качества кода. Не стоит ограничиваться тестами и code review. Статический анализатор — один из тех инструментов, которые могут помочь программисту писать более качественный код позволяя полезнее использовать то время, которое было бы потрачено на поиск ошибки, допущенной из-за какой-нибудь опечатки. Но не стоит забывать, что статический анализатор — инструмент регулярного применения. И если вы ещё не используете его — рекомендую загрузить PVS-Studio, проверить свой проект и посмотреть, что же интересного удастся найти.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Vasiliev. Analysis of PHP7.
Читайте также: