А если по этому несуществующему по https:// обратиться, тоже работает?
Если нет и надо чтоб работало, пишите в личку.
Смотря что считать доменом. Если 2го уровня, то наврядли. А 3го есть разные всякие если поискать.
К примеру http://pp.ua/
Регистрировать через любого регистратора: http://drs.ua/rus/registrars.html
Потом телеграм ботом подтвердить. Также и продление - раз в год в телеграме.
Такой еще есть у меня один: http://eu.org/
Да, можно и shell_exec. Не знаю что тоже самое, у меня работает, один за другим запускаются, а предыдущие завершаются, ничего не зависает.
Короче ладно... не важно.
Конечно, откуда ж возьмется HTTP_HOST? Эти переменные берутся из веб-сервера, просто PHP про них знать не может, скрипт же не из под сайта запускается, а просто сам по себе.
И REMOTE_ADDR чей в данном случае должен быть? Чисто логически, если никакого "remote" вообще не происходит, все локально. :]
Да не в кроне, а в самом скрипте это надо. get_headers, curl - это все не то.
`wget -O - $config[http_home_url]script.php?num=$num >/dev/null &`;
Вот эта штука если в самом скрипте запускает дочерние, то все отлично. У меня все заработало как положено по крайней мере.
Ладно...
Да, проверил по-быстрому у себя - тоже виснет. Но если добавить >/dev/null все ок становится.
Попробуйте вместо:
get_headers($config['http_home_url'].'script.php?num='.$num);
вставить:
Потом запустить браузером и наблюдать за логами. Оно должно 1 раз отработать и закончиться в браузере, но отдельно запустится wget процесс с еще одной копией, потом тот выйдет и еще один и так далее до конца - в логах должна быть последовательность через около 2сек (sleep 2 ваши) запросов типа script.php?num=2 и т.д. по порядку. Ну и конечно же сайт должен работать нормально в это время.
Во-первых, как верно заметили, хоть оно и пишет что таблицы на диск пишутся, но фактически ведь пишутся в память, т.е. на физический диск ничего не пишется.
Во-вторых, есть переменные tmp_table_size и max_heap_table_size - нужно их сделать размером больше чем те записываемые таблицы. Прописать в my.cnf и проверить:
show variables like '%_table_size';
И главное... с чего взяли что суть вашей проблемы в самом процессе создания таблиц на диск? Может из-за того что когда диск во время бэкапа тормозит, тормозит чтение из базы во время запроса. Если после переноса tmpdir на tmpfs ничего не улучшилось, то врядли здесь надо искать проблему. По хорошему конечно вся база должна сидеть в памяти целиком и с диском обмениваться лишь иногда.
Да и вообще, уверены что зависание именно от нагрузки на диск во время бэкапа, а не нагрузки на cpu например? Бэкап это ведь и архивирование обычно - страшное дело если сделано абы как, не однопоточно :)
Вот так бы попробовать:
$_GET['num'] везде меняем на $argv[1]
get_headers($config['http_home_url'].'script.php?num='.$num); меняем на:
`php script.php $num & exit`;
в крон просто добавляем:
php script.php
Т.е. скрипт запускается без параметров (num становится = 0), выполняется прогон первой ссылки, дальше запуск новой копии скрипта уже с параметром $num и выход. Т.е. не ждет завершения его. Все, крон закончил работу, дальше остались лишь висеть дочерние копии, которые также отрабатывают, запускают следующую и завершаются.
Надо пробовать, но теоретически должно работать как положено. И при этом сайт/веб-сервер вообще не участвует, на его работе не должно отражаться никак.
Если же из под php-cli запускать не вариант (есть какая-то привязка к веб-серверу, путям каким-то, переменным и т.д.), то все тоже самое реализуется через "wget http://сайт/script.php?num=$num & exit" вместо "php script.php $num & exit" (ну и опять используем $_GET['num'] вместо $argv)
Вы запускаете цепную реакцию и парализуете веб-сервер.
Если правильно понял что оно делает, то запускается скрипт, который не завершается пока не закончится запуск внутри его же самого, а внутри того еще он же и так далее пока не закончатся worker'ы веб-сервера.
Надо смотреть логи, но по-идее оно вообще у вас не работает никак т.к. на последнем свободном worker'е происходит снова запуск скрипта и точно также как вы не можете больше ни одну страницу открыть, так и скрипт этот также стоит в ожидании свободного worker'а, который скорей всего появляется, но позже после таймаута (например max_execution_time в php или еще какой-то таймаут выше, смотря что за веб-сервер(ы) это все обрабатывает).
Но естественно это не выход в случае если ссылок там сотни, тысячи,...
Короче, все не правильно сделано изначально. Скрипт должен запуститься, отработать, запустить следующую копию, а сам завершиться не дожидаясь результата ее выполнения. Или должен быть некий "мастер"-скрипт, который запускает дочерний один, ждет ответа (если это нужно), потом следующий и т.д. Сейчас же по цепочке они друг друга запускают и первый (и все последующие) ждут пока не закончит работу последний в итоге все просто в подвисшем состоянии и ничего не работает пока не сработает какой-то таймаут и так далее до конца.
Точно такая же картина у меня на паре других хостеров.
Суть - сайт изначально по http://, но откуда-то попадает в индекс https:// (которого у меня нет и содержимое в кэше от другого сайта на том же хосте) плюс такой же левый поддомен mail. с тоже левым содержимым.
Т.е. панель автоматом зачем-то создает этот поддомен и уж не знаю как но он попадает в индекс гугла.
Ваш правильный http:// в индексе тоже есть
Короче проблема действительно существующая и надо лечить. Как - выше уже сказали, сделать и себе https:// версию. Плюс я бы добавил mail. поддомен. Чтоб он просто был, хоть пустой страницей (а не чужим сайтом как сейчас). Плюс добавить на эти проблемные места временно ссылок (т.к. ссылок на эти https:// и mail. нет ниоткуда, в моем случае по крайней мере). Гугл пройдет по ним и переиндексирует. Позже когда пропадет контент чужих сайтов можно поставить редирект на основной свой http:// и все. Ну или переехать на https:// основной. Кое-где уже немного получилось так вылечить, но пока не полностью...
Ничего не путаю. Ну смотря для чего конечно серверок используется и кем. Но если речь про хостинг сайтов, то нет, не нужно всем пользователями иметь (и разводить там страшную помойку) доступ в общий /tmp.
У каждого свой должен быть. Собственно так и сделано у меня везде много лет уж как.
И, еще раз, пользователю, под которым работает nginx достаточно лишь иметь доступ к файлам сайтов, к статике которую он раздает сам. И больше никуда ему нет надобности иметь доступа.
Хотя если и nginx и php-fpm работают от одного и того же пользователя, то да. Но зачем так делать, это уже отдельный вопрос.
PHP же наверняка запущено от другого пользователя (или нескольких разных), вот он и должен иметь доступ к папке, указанной в session.save_path и причем она может быть отлична от tmp папки пользователя. Т.е. сессии отдельно, темп отдельно.
