Иван Корюков

Как уже написали в комментарии - то где искать стили решает приложение и по хорошему надо в каждом бэке сделать пути для подгрузки статики настраиваемыми.

Однако, если все бэки находятся на одной машине, можно подставить костыль.
Вы можете создать особый location, даже несколько, которые будут искать запрошенный файл сначала в одной папке, потом в другой, потом в третьей.

location ~* \.(css|js)$ {
    root /path/to/back1;
    try_files $uri @back2;
}

location @back2 {
   root /path/to/back2;
   try_files $uri @back3;
}

location @back3 {
   root /path/to/back3;
   try_files $uri =404;
}

Если один из бэков находится не на этой же машине, то можно его поставить в конец и делать на него проксирование:

location @back3 {
   proxy_pass http://external-service.com;
}

Ещё, можно рассмотреть вариант с условиями, которые смотрят на загловки запроса, ну там referer какой-нибудь или origin, и в зависимости от этого проксируют на тот или иной бэк.

Потому что паттерн надо в кавычки брать. А ещё в греп надо явно указывать что паттерн это регулярка опцией -E
Сделайте
grep - E 'ваш паттерн'

Используйте заголовок редиректа
header("Location: $link");

Если активность в репозиторий высокая, то, вероятно, уже никак.
А если никто не успел сделать коммит после вас в главную ветку, то вы можете сделать git reset на коммит до мержа и потом git push --force. Конечно, если вы имеете на это право)

У вас основная секция server слушает 443, а новые правила редиректов вы вставили в server, который слушает 80 и предназначен для редиректов http -> https
Кроме того, в www редиректе вы не меняете хост, т.е. даже если он отработает, то он вызовет бесконечный редирект.

В этом нет ничего криминального. Если вам надо именно так - делайте. Если видите способ упростить систему - упрощайте.
Главное не забыть прокинуть реальный ip и схему в заголовке.

Кстати, k8s например примерно так и работает. Там 80,443 порт слушает т.н. ингрес - обычно тот же nginx, конфиг которого задаётся через yml файл. И вот он принимает все запросы и в зависимости от настроек проксирует их на бэкэнды, в том числе и на внутренние nginx'ы.

Обычно, проверка на то что программа уже запущена, делается через создание т.н. lock файла.
Вам нужно в начале работы скрипта проверить - создан ли файл.. ну например /var/www/site/manage.lock
если да, то завершить программу т.к. уже работает другой процесс,
если нет - создать такой файл, продолжить выполнение программы, а перед завершением удалить файл.

Если говорить об определении дочерних процессов, то у ps богатые возможности по фильтрации и форматированию вывода. Получить PID дочерних процессов зная PID родительского можно вот так:
ps --ppid=1234 -o pid

Можно использовать регулярное выражение

let allCaps = !/[a-zа-я]/.test(myString);

Чтобы sql запрос выдал вам только уникальные строки необходимо в секцию select добавить слово distinct.
Вот так:
select distinct id, name, date...
Примерно то же самое можно сделать и через eloquent builder
Model::query()->distinct()...

Однако это работает именно со строками ответа.
Если же у вас строки ответа разные, но дата повторяется, то там нужно более сложное решение.

На моей памяти Windows Terminal никогда с tmux нормально не работал. И ConEmu тоже.
Адекватно себя ведут только терминалы из cygwin и mingw. Чтобы получить такой терминал достаточно установить git и открыть git bash.

Не изобретайте велосипед и найдите библиотеку для работы с soap. Протоколы для того и придумываются, чтобы стандартизировать какие-то вещи и потом использовать библиотеки.

nohup - это команда bash, которая просто указывает самому bash'у что фоновому процессу не надо отправлять сигнал HUP при завершении работы.
& это тоже фишка bash, позволяющая перевести процесс в фон

Проблема в том что php это вам не bash и он наверное сам отслеживает состояние запущенного им процесса.

Попробуйте использовать setsid.
В отличие от nohup это полноценная программа, которая запускает указанную в качестве аргумента программу в отдельной сессии. Как только целевая программа запущена setsid завершает работу. Это должно "отпустить" php почти моментально.

Чтобы программа работала "в фоне", она должна либо сама позаботиться о том чтобы не блокировать консоль и не умирать при закрытии баша, либо доверить это специальной программе.

Как уйти в фон самостоятельно:
Процессы (работающие программы) имеют идентификаторы и знают кто их запустил, посредством хранения id родительского процесса. Т.о. у нас есть дерево процессов. Родительский процесс может управлять дочерними, и он должен при своём завершении завершать и свои дочерние процессы. Если он этого не сделает, то дочерний процесс сменит родителя на процесс с id = 1, т.е. на init процесс. Поэтому чтобы уйти в фон, ваша программа должна всего лишь остановить её родительский процесс.
Проблема в том, что родительский процесс для программы, которую вы запускаете в консоли - это сама консоль и нам не надо чтобы она закрылась.
Поэтому уходящие в фон программы перед остановкой родителя увеличивают уровень вложенности - т.е. запускают свою копию, и эта копия, будучи дочерней для первого процесса программы, убивает уже не баш, а вспомогательный родительский процесс.
Другой момент - это отвязаться от консоли. Тут всё просто - надо перенаправить stdin, stderr и stdout в файлы.
Ну и наконец надо позаботиться об управлении демоном, ведь пока что нам не остаётся ничего другого, кроме как посылать ему сигналы командой kill. Чтобы реализовать более понятные команды, надо сделать две вещи:
1) во время ухода в фон сохранить в файл pid результирующего процесса
2) написать немного кода в самой программе или во вспомогательном скрипте, который, при вызове его в консоли, будет читать pid из файла и манипулировать процессом.

Такая функциональность часто выделяется в отдельную библиотеку, можно поискать в документации или на гитхабе.

Другой вариант - использовать вспомогательные программы.
С одной стороны у нас есть возможности самого баша - jobs т.е. фоновые процессы, которые однако умирают при закрытии консоли. Чтобы это обойти есть команда disown и программы nohup и setsid.
Они позволяют так или иначе получить процесс отвязанный от баша. Однако управлять процессом можно будет только сигналами.
С другой стороны есть менеджеры процессов. Например supervisord или pm2. Это такие программы, которые умеют уходить в фон и умеют, уже будучи демоном, запускать другие программы и управлять ими.

Ну и наконец всегда есть главный менеджер процессов вашего компьютера/сервера - это система инициализации, которая сейчас почти везде - systemd. Делает то же самое что и обычный менеджер процессов, но ещё и позволяет управлять последовательностью запуска процессов.

Итог: выбирать способ демонизации процесса необходимо исходя из стабильности его работы. Если это сервер, который должен работать месяцами и запускаться при старте системы - то надо использовать систему инициализации. Так делают Nвеб-сервера, базы данных и всякие капитальные сервисы.
Если процессы более динамичные и их надо периодически запускать и останавливать, то лучше взять менеджер процессов.
Если это совсем уж мимолётное желание запустить программу в фоне, пусть поработает а там остановлю, то можно не заморачиваться и отвязать её от баша тем или иным способом.

Возможность самостоятельно уйти в фон и реализация собственных команд управления процессом нужна только если у вас наполеоновские планы и вы хотите дать пользователям возможность запускать вашу программу на разных ОС.