вт, 17 сент. 2024 г. в 10:10, Hennadii Makhomed <g...@csdoc.com>:
> On 16.09.2024 21:06, Konstantin Pavlov wrote: > > >>>> а как Вам идея вместо двух unit-файлов nginx.service > >>>> и nginx-debug.service использовать только один unit-файл > >>>> nginx.service и использовать alternatives для переключения > >>>> бинарника /usr/sbin/nginx между release и debug версиями ? > >>> > >>> Мы поддерживаем несколько разных ОС в наших пакетах на nginx.org (и > >>> еще больше - для коммерческой версии), и не во всех них есть > >>> поддержка alternatives. По этой причине не хотелось бы это > >>> реализовывать для какой-то одной конкретной ОС если нельзя сделать > >>> везде одинаково. > >> > >> это можно сделать везде одинаково, на всех Linux/UNIX системах. > >> > >> если же переключение между release / debug версями происходит с помощью > >> двух отдельных сервисов nginx.service и nginx-debug.service, то в таком > >> случае переключение между ними происходит с потерей соединений клиентов > > > > Делать столько уникальной логики, опять же уходя от привычной многим и > > документированной системы alternatives, для очень редкой ситуации когда > > нужно запустить дебаг-версию? > > Моя идея с симлинком /usr/sbin/nginx который указывает на release > или debug версию бинарника nginx - это плохая идея еще и потому, > что по стандарту FHS - "/usr should be shareable between various > FHS-compliant hosts and must not be written to. Any information > that is host-specific or varies with time is stored elsewhere". > > alternatives использовать также нельзя, потому что > не во всех ОС есть поддержка alternatives и потому что > использование системы alternatives увеличивает хрупкость. > > > Кажется, гораздо проще, если уж нельзя воспроизвести проблему на стенде, > > сделать временно: > > > > mv /usr/sbin/nginx /usr/sbin/nginx.bak > > > > mv /usr/sbin/nginx-debug /usr/sbin/nginx > > > > service nginx upgrade > > > > А что делать в том случае, когда файловая система /usr смонтирована > в режиме read-only и не удается воспроизвести проблему на стенде? > если вы попали в такую ситуацию - стоит задуматься, зачем вы в нее попали. желание переименовывать файлы и файловая система, смонтированная в режиме ead-only - как бы немного друг другу противоречат for the sake of simplicity - не надо пытаться решать задачу переименования файла на read-only системе, пожалуйста > > Да и в том случае, когда файловая система /usr доступна на запись - > переименование исполняемых файлов - это неудобно как для самих > пользователей, так и для инженеров технической поддержки, > которые будут общаться с пользователями и помогать им. > > Какое решение этой задачи будет более оптимальным? > > service nginx upgrade > > service nginx upgrade-to-debug > > service nginx upgrade-to-release > > Как технически это реализовать? > > Upgrading Executable on the Fly > https://nginx.org/en/docs/control.html#upgrade > > Когда старый master-процесс nginx делает этот шаг: "then starts > a new executable file that in turn starts new worker processes" > необходимо, он мог понимать, какой именно бинарник ему следует > запустить на выполнение - release или debug вариант бинарника. > > Для этого - надо передать работающему master-процессу nginx > в процессе online upgrade дополнительно один бит информации. > > когда передается 0 бит - тогда запускается /usr/sbin/nginx > когда передается 1 бит - тогда запускается /usr/sbin/nginx-debug > > Каким образом это можно сделать? С помощью pid-файла. > > В нормальном режиме работы pid-файл > имеет владельца root:root и права доступа 0644 (-rw-r--r--) > - в таком случае master-процесс nginx делает online upgrade > на обычную, release-версию бинарника /usr/sbin/nginx > > Если же в момент получения master-процессом nginx сигнала USR2 > на его pid-файл установлены права доступа 0664 (-rw-rw-r--) > - в таком случае master-процесс nginx делает online upgrade > на отладочную, debug-версию бинарника /usr/sbin/nginx-debug > > В configure arguments при сборке задается > > --sbin-path=/usr/sbin/nginx > > было бы хорошо добавить еще один аргумент, > > --sbin-debug-path=/usr/sbin/nginx-debug > > по умолчанию, если явно не задано - добавляется > подстрока "-debug" к значению аргумента --sbin-path > > в таком случае изменение логики работы nginx > будет минимальным в процессе online upgrade: > > если pid-файл nginx имеет 1 бит в поле права на запись для группы, > тогда запустить бинарный файл, который задан в --sbin-debug-path > если 0 бит - запустить бинарный файл, который задан в --sbin-path > > скрипт для выполнения команды service nginx upgrade-to-debug > > файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-debug > > =================================== > > #!/usr/bin/sh > # > # Legacy action script for "service nginx upgrade-to-debug" > > pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed > 's/^PIDFile=//' | tr ' ' '\n'` > > chmod --quiet g+w ${pidfile} > > exec service nginx upgrade > > =================================== > > скрипт для выполнения команды service nginx upgrade-to-release > > файла /usr/libexec/initscripts/legacy-actions/nginx/upgrade-to-release > > =================================== > > #!/usr/bin/sh > # > # Legacy action script for "service nginx upgrade-to-release" > > pidfile=`/usr/bin/systemctl show -p PIDFile nginx.service | sed > 's/^PIDFile=//' | tr ' ' '\n'` > > chmod --quiet g-w ${pidfile} > > exec service nginx upgrade > > =================================== > > существующий скрипт для выполнения команды service nginx upgrade > файл /usr/libexec/initscripts/legacy-actions/nginx/upgrade > - остается без изменений. > > и тогда - в любой момент времени можно будет сделать > on the fly переключение между release и debug версиями > nginx без потери клиентских соединений, всего одной командой. > > причем, этот метод будет работать на любой версии Linux > > и тогда можно будет обойтись всего одним unit-файлом nginx.service > и можно будет полностью отказаться от unit-файла nginx-debug.service > > такой вариант решения будет иметь максимальную надежность, > потому что не будут использоваться симлинки и alternatives > > будет требовать минимальное количество изменений в коде nginx > > и при этом - будет максимально удобным для пользователей nginx, > потому что позволит переключаться между release и debug версями > nginx без потери соединений выполнив всего лишь одну команду. > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru >
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
