Связка exec() + mysqli_query(), что тут вообще происходит?

Question

[phenya]

Имеется большой проект со сложной разветвлённой бизнес-логикой, работающий в связке php-fpm + nginx. В качестве БД выступает mysql. И в этом большом проекте есть маленькая такая проблема, которая, как таковая, к самому проекту никак не относится, зато проект теперь относится к ней. Очень плохо относится.
Итак:
- имеется абстрактная таблица в БД `table` с полями `id`, `name`
- имеется простейший php-скрипт, который инициализирует подключение и пытается сделать выборку

<?php
//1.php
conn = mysqli_connect('localhost', 'user', 'pass', 'db_name');
$res = $conn->query('SELECT * FROM `table` WHERE `id` = 1');
var_dump($res);
mysqli_close($conn);

- имеется второй php-скрипт, который запускает первый с помощью exec()

<?php
//2.php
exec('php -f 1.php', $output);
var_dump($output);

Если теперь запустить 2-й скрипт, то все отлично отработает и $output будет не пустым. Но стоит нам только поменять выборку в 1-м скрипте таким образом, чтобы нам пришел пустой результат и опять выполнить 2-й скрипт, то всё - $output пустой (а должен быть дамп пустого объекта). Причем просто происходит "вылет" 1-го скрипта при вызове

$conn->query('SELECT * FROM `table` WHERE `id` = 2');  // пользователя с ИД = 2 не существует

без ошибки, без предупреждения и вообще вывода какой-либо информации(в логах тоже ничего). 1-й скрипт просто тихонько умирает, а 2-й вынужден показывать пустой массив. Причем такое поведение только в случае, если 1-й скрипт запустится посредством вызова exec()(shell_exec(), system()), если же 1-й скрипт вызвать из консоли ручками (php -f 1.php), то все нормально отработает: запрос ушел, а ответ пришел в виде пустого объекта.

Ну а вопрос, как обычно, вечный - кто виноват? и что делать? Может сталкивался кто? Или есть какие-то идеи?

php - 5.6.31
с mysql php общается через mysqlnd (5.0.11-dev - 20120503)

Comments

[Сергей Сергей]

Объединить скрипты? Сделать из первого функцию.

[Павел Волынцев]

Могу предположить, что ...
1. Второй скрипт не знает полный путь к первому. Используйте абсолютные пути
2. Второй не выполняется. Сделайте тестовый echo до запроса и после var_dump
3. Ещё надо убедиться, что именно в $output выводится результат. Попробуйте выполнить exec("php -h", $output) и посмотреть вывод

[phenya]

Павел Волынцев: нет, с этим все впорядке - всё выполняется, пути в оригинальном скрипте абсолютные. Проблема именно в выполнении mysqli_query() вызванной в скрипте, запущенном через exec

[phenya]

Сергей Сергей:
в рамках реальной задачи не получится, в реальном проекте
1-й скрипт: скрипт обработки очереди, должен запускаться в фоновом режиме
2-й скрипт, контроллер управления 1-м скриптом посредством http (но первый может запускаться и кроном)

[Сергей Сергей]

Ну если echo отладка говорит, что всё хорошо, значит можно применить костыль с проверкой на пустой var_dump и имитацией пустого объекта на выходе. Может даже придется прописать переходы через try/catch.

Но для смеха, может переменные окружения разные?

[phenya]

переменные окружения одинаковые. Костыли не подходят, потому-что после запроса должно выполняться еще очень много всего ), а mysqli_query просто вылетает обрывая скрипт. Тут такое ощущение, что где-то в самом интерпретаторе php вываливается какой-то segmentation fail и все обрывается

[Сергей Сергей]

Ну и опять смелое предположение:
после запроса есть ошибка в логике обработки пустого массива, например, бесконечно рекурсивный while, который останавливается интерпретатором внутри exec и не фиксируется в логах по причине какой-то допустимости.

Ну и не рассказано ничего про @/try-catch запуски – из поведения костылей можно почерпнуть немного сведений.

И костыль уровня "кресло-каталка":
в первом скрипте делать exec( 'mysql -u*** -p*** `select ...`' ) и парсить этот вывод, и посмотреть опять пустой результат.

[phenya]

Сергей Сергей: спасибо, за предложенные варианты )

после запроса уже ничего не выполняется, даже если след. строчкой будет die('1'); он не выполнится )
костыль уровня "кресло-каталка" мог бы помочь в случае абстрактных примеров приведенных в описании, но не в реальном проекте, потому-что выполнение скрипта №1 обрывается где-то в одном из многочисленных модулей, подключаемых до начала выполнения основной логики 1-го скрипта (авторизация, сбор статистики, логирование запросов).
Т.е. я хочу донести, что для воспроизведения такого поведения достаточно этих 2 надуманных примеров. Но при этом реальный проект намного больше и там костылями не обойтись (иначе я бы их уже давно поставил )) )
Сегодня попробую накатить проект на более свежую сборку с php 7.0 и mysqlnd 5.0.12 версией, потому-что сдается мне, что это баг именно на уровне ядра самого php

Answer 1

[Игорь]

А вы ничего не путаете? :)
Даже если вы в 1.php сделаете синтаксическую ошибку, то 2.php отработает успешно и выдаст вам ее в output:

php -f 2.php
array(2) {
  [0]=>
  string(0) ""
  [1]=>
  string(87) "Parse error: syntax error, unexpected ')' in 1.php on line 2"
}

Может быть проблема с 1.php? В любом случае тут:

conn = mysqli_connect('localhost', 'user', 'pass', 'db_name');

перед conn не помешал бы знак $

Comments

[phenya]

примеры в описании - упрощенные, я их привел только для лучшего понимания сути взаимодействия 2-х скриптов в результате которого проявляется такое поведение функции mysqli_query вызванной в скрипте, запущенном через exec.