Сергей Соловьев

Отсутствие реакции на SIGTERM при продолжающемся потреблении CPU это примечательно. Но без -dbgsym и GDB ничего определённого выяснить фактически не удастся. Суть - как-то попали в какую-то ветвь кода, которая не считалась что может занимать продолжительное время и вызов обработчика сигналов CHECK_FOR_INTERRUPTS там не был предусмотрен. Из вариантов навскидку где возможно в 16.х наступить - dblink или fdw, create index using hash. Традиционно, ещё могут быть index scan по gin или gist, не в первый раз находятся у них такие грабли.
Как минимум, удостовериться, что используется свежая минорная версия. Завтра 16.9 выходит.

Ну, это из предположения что весьма подозрительный watchdog: BUG: soft lockup тут ни при чём. Что это такое я вряд ли подскажу. Выглядит нехорошо.

Такс, это всё про оставшийся процесс.
Про сам the database system is shutting down
При crash recovery делается immediate stop, все backend которые не завершаться за 5 секунд получат SIGKILL. Который, естественно, проигнорировать уже не могут, потому что процессу про SIGKILL никто даже и не скажет, его просто снимет ядро ОС.
Значит, перед всеми the database system is shutting down был received smart shutdown request или received fast shutdown request, который кто-то скомандовал явным образом. Оба режима штатного выключения не делают SIGKILL, а именно дождутся корректного завершения процесса. В случае с багом, когда процесс не отреагировал на SIGTERM, ну, вечно ждать и будет. Других вариантов кроме SIGKILL тут нет.

Если логи ещё сохранились на дату shutdown request - то смотреть что там делали с системой, что кто-то скомандовал stop или restart базе. Если не вмешательство администратора, то может быть какой-то аналог unattended-upgrades?

Использовать один и тот же прокси или VPN сервер.

В postgres можно искать по геоиндексам при помощи postgis.
Для текстового поиска по описанию в постгресе есть полнотекстовый поиск.
Произвольные поля можно добавить через колонку с jsonb.

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

как фильтровать трафик для Youtube чтобы была Русская реклама

На настоящий момент - никак, реклама (втч. монетизация) во всех сервисах гугла, распространяемая или таргетированная на ру сегмент - отключена, в связи с санкциями. Если Вы имеете ввиду т.н. "интеграцию", то интеграция вшита в ролик и не зависит от геолокации, языка, устройства итп.

1. Юридическое лицо обязательно придется завести

2. Налоговая в любом случае увидит тут признаки дохода и ты будешь обязан взимать НДФЛ с исполнителей, как налоговый агент.
Вот и требование отчитываться в налоговую.
Вот тебе, получается, нужно узнавать полные данные и ИНН исполнителей.
Вот и закон о персональных данных кокетливо машет рукой, а РКН ждёт от тебя стопку бумаг о том, как ты с этими ПД работаешь и как защищаешь. Очень возможно, что придётся ещё потратиться, чтобы всем требованиям соответствовать.

3. А ещё тут очень легко можно попасть на отмывание денег. Возможно, для того что ты хочешь сделать, нужно ещё получать лицензию. Стоит проконсультироваться с юристом по поводу того, какой у тебя ОКВЭД тут будет.

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

Без юридического лица можно попробовать крипту, но тут тоже есть нюансы, начиная опять же с комиссий(говорят есть варианты с небольшой комиссией) и волатильности (по идее есть стейблкоины, но и они умеют обваливаться), заканчивая серым статусом, зато всего остального получится избежать.

Условная поездка - это считанные десятки запросов к серверу (если правильно websocket или любые другие двухсторонние протоколы), даже очень криворукие разработчики могут реализовать порядка секунды на запрос (обычно сотни-тысячи запросов в секунду на ноду, а очень хорошие разработчики могут обеспечить порядка 10к-100к запросов в секунду на ноду)...

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

По больше бы таких интересных вопросов.

Задал ваш вопрос openai:o1-preview, ответ выглядит очень логичным:

Посмотри, что показывает cat /proc/sys/kernel/random/entropy_avail

системд не использует интерпретатор командной строки, потому запись ExecStart=/home/mtr.sh не правильна в корне. ты пытаешься исполнить баше-скрипт, а системд не подставляет баш в качестве дефолтного исполнителя.

говоря проще, первым параметром ExecStart должон быть бинарный исполняемый файл.
ExecStart=/bin/bash /home/mtr.sh
---------
В процессе обсуждений выяснили что проблема была в ограничениях доступа от selinux

1. Не надо путать "класс" и "экземпляр класса" (объект)

2. dynamic_cast не на много дороже, чем вызов виртуального метода. На сколько это критично для твоих "критичных мест" - это уже тебе решать)

3. То что ты в коде делаешь dynamic_cast - это странно и уже как-то нехорошо попахивает. Зачем тебе вообще тогда наследование, если какие-то конкретные классы ты по особенному обрабатываешь?

Да, называется веб-сокеты.

Нет, если в случае чего, Вы сможете доказать, что Ваша программа так же не является вирусом ("Создание" УК РФ Статья 273). Вы должны понимать, что крайнего все равно придется найти...

Когда каскадное обновление это плохо?

Каскадное обновление - в большинстве случаев это... глупо.

Вспомним, что это вообще такое.

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

По смыслу в основной таблице это поле - как минимум уникально. То есть с точностью до NULL оно является идентифицирующим - то есть если в этом поле не NULL, то определённое значение однозначно идентифицирует строго одну запись. В большинстве случаев же поле в основной таблице, на которое установлена ссылка в подчинённой таблице, вообще является первичным ключом, соответственно не может быть NULL и является истинно идентифицирующим.

Что же есть каскадное обновление? Это изменение связанного значения в подчинённой таблице, если изменяется значение основной таблицы. Ну то есть если изменяется (вспоминаем сказанное выше) значение первичного ключа или поля, объявленного уникальным. В основной таблице. Ага...

Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

Практически всё то же относится и к корректировке просто уникального поля. За исключением случая, когда выполняется каскадное изменение значения поля, которое в основной таблице получило значение NULL. То есть когда выполняемая операция по смыслу является не обновлением, а "мягким удалением" основной записи с каскадным удалением всех подчинённых. Правда, на вопрос, как отличить мягко каскадно-удалённые подчинённые записи от мягко явно-удалённых, и как определить, с какой основной записью была связана мягко удалённая подчинённая, не залезая в журнал или бэкап, ответа никто не даст. А получается, что даже в случае исключения всё делается через "универсальный интерфейс", то есть косяк в проектировании структуры имеется и в этом случае.

Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.