id IN (...).
server {
server_name mirror.mydomain.com;
location / {
proxy_pass http://proxied-site.com;
proxy_set_header Host $proxy_host;
}
}kill SIGHUP
Демон должен установить обработчик этого сигнала - при получении сигнала перечитывать конфиг.
Если меняются часто, то помимо самого "рабочего" сокета, который ждет этот long-pool запрос, открывают еще один - контрольный сокет (слущающий ru.php.net/manual/en/function.socket-listen.php) на котором ждут появления команд/новых параметров. Он может слушать локальный TCP/UDP порт или UNIX сокет, а то и pipe. Правда тогда появляется проблема, что нужно контролировать сразу 2 сокета - тут уже нужны потоки или select/epool.
Ну и третий вариант - просто периодически опрашивать БД/перечитывать конф-файл, например после окончания long-pool запроса или по sleep() если запросов нет. Но это уже детский сад))
/(FROM|UPDATE|ALTER)\s+{([\w\d_]+)\}/iU а вы приводите ломающий ее пример UPDATE {table} SET `text`="пример запроса: SELECT * FROM {table}"… При том, что запросы, включающие в себя данные, уже года 4 как нормальные люди не используют. Есть же плейсхолдеры (в похапе их поддерживает как минимум PDO). Т.е. будете писать UPDATE {table} SET `text`=:text WHERE id IN( SELECT id FROM {other_table}), проводить все ваши замечательные замены и потом уже средствами PDO биндить данные к запросу.SELECT * FROM {#$table$#}. Ну и крайний случай — пишите полноценный парсер SQL по всяким BNF правилам. Хотя тогда скорее всего просто зря потеряете кучу времени.
VALUE mfd.php_nexttime 768 10 флаг это 768 а 10 — длина ответа (10 байт). Только не совсем понял почему у вас для одного и того же ключа разные флаги (ведь там оба раза одно и то же значение было??)else:
val = buf#вот так!!
self.debuglog("unknown flags on get: %x\n" % flags))
Loaded Configuration File - (none). В вашем случае, судя по тому что и там и там опция Configuration File (php.ini) Path - /usr/local/etc то fastcgi процессу не хватает прав на чтение файла /usr/local/etc/php.ini