Интересно, что руководит людьми из boost, когда они проверяют версию ядра на наличие определенного syscall'a, а потом используют функцию из glibc? :_)

Ну вы бы хотя бы на наличие _Nr_* макроса ориентировались, а не на эту магическую цифру...

Дополнительный мем в том, что челики, которые юзают musl тоже с этим столкнулись, но этот патч мне нравится куда меньше

https://github.com/boostorg/process/pull/376/files

Для тех, кто пишет на C++ и использует vcpkg. Я тут закинул пару системных библиотек, чтобы без боли можно было линковаться статически.

- libcgroup (v3.1.0) https://github.com/microsoft/vcpkg/pull/39647
- libaudit (v4.0.1) https://github.com/microsoft/vcpkg/pull/39587

Обе сильно порезаны при сборке, а libcgroup вообще нужно чинить в апстриме, так как при отключении интеграции с systemd ломается umbrella include, поэтому придется определять _LIBCGROUP_H_INSIDE и писать свой мегаинклуд при использовании.

Нет, я знал, что boost частично разрабатывают не иначе как no-life аутсайдеры, но это уже вопиющее ЧСВ.

Морозить PR 2 недели от 2х людей, чтобы потом скопировать изменения, которые были предложены и залить их ПОД СВОИМ именем, да еще и НЕПРАВИЛЬНО, это конченый аутизм.

Сегодняшний герой залил патч в boost/process/v2, который добавляет проверку версии glibc и MUSL при сборке проекта, чтобы понимать, можно использовать close_range() или нет. НО! Во-первых, проверка наличия syscall'a опираясь на версию ядра хоть и имеет место быть, но ненадежна, лучше проверять SYS_close_range. Во-вторых, если сборка будет проходить на новом ядре, НО со старым glibc (а это частый кейс, чтобы расширить совместимость), вся программа сломается к херам и удачи это отладить. Почему так? А потому что он fallback'ается на сырой системный вызов. Нужно добавлять возможность явно отключать такие вещи. Типичный программист "на моей машине работает".

В-третьих, сука, еще и ЧСВ своё тешит тем, что копирует предложенные изменения под своим именем, типа это всё он подумал.

Процессы в Linux, и, в частности, распределения pid, tgid, ppid, sid, pgid это та еще путаница, в которой лучше рабираться по исходникам. Почему?

Вот есть большая статья, где чел пишет:

It’s true in general that TIDs and TGIDs are sometimes the same as described above, but it’s possible to construct a fresh userspace process in which the single initial thread has a TID that doesn’t match its TGID. If you execve() in a multithreaded process from any thread other than the initial thread, the kernel will kill all other threads, and make the exec-ing thread the leader of the thread group. The TID of the thread doesn’t change, and so the new process will execute on a thread whose TID doesn’t match its TGID.

Правда ли это? Конечно, нет. И вот, казалось бы, достаточно много ссылок на исходные коды, но вот до этих исходных кодов он, видимо, не добрался.

- Вызов do_thread()
- "Трансфер" всех идентификаторов процесса к исполняемому от лидера группы

/*
 * An exec() starts a new thread group with the
 * TGID of the previous thread group. Rehash the
 * two threads with a switched PID, and release
 * the former thread group leader:
 */

 /* Become a process group leader with the old leader's pid.
  * The old leader becomes a thread of the this thread group.
  */

Просто для справки: после exec() pid всегда равен tgid.

UPD:
Можно проверить даже проще, буквально написав так, как он описал:

int main(int argc, char *argv[]) {
    std::cout << "tgid: " << ::getpid() << ", pid: " << ::gettid() << std::endl;

    std::thread([&argv] {
        std::cout << "tgid: " << ::getpid() << ", pid: " << ::gettid() << std::endl;
        char *const args[] = {"/usr/bin/ping", "8.8.8.8", nullptr};
        execv("/usr/bin/ping", args);
    }).join();
}

А затем посмотреть cat /proc/$(pidof ping)/status

UPD 2:
По всей видимости поведение с "выравниванием" pid и tgid появилось только в 4.19 (патч). Но всё же, на момент написания статьи (5 июня, 2024) поведение уже было иным, нежели описано в статье.
Немного поменяю мораль: проверять нужно всё дважды, особенно, если речь идет о Linux.

Вот мы все любим шутейки про "сделано 90% работы, осталось сделать оставшиеся 90%", "последние 10% качества стоят нам 90% усилий", и так далее.

Я сейчас скажу довольно очевидную вещь, которая мне довольно долго не давалась.

Вот это вот умение вовремя остановиться, и сказать, что "от нас никто не ждет идеального результата, но ждут определенного качества за определенные деньги/ресурсы", пресловутое "и так сойдет" - это очень важно, и нужно иногда бить себя по рукам, и игнорировать свое чувство прекрасного, которое требует "еще немножечко better".

Для тех разработчиков и админов, кто столкнулся с проблемой тепловой смерти CentOS 7, но которым до сих пор нужно активно использовать ее в контейнерах/VM.

Скорее всего, просто пересобрать контейнер на CentOS 7 уже не получится, но есть варианты "оживить" ОС и обезопасить себя, отзеркалив некоторые репозитории и перенастроив mirror'ы.

Шаг 1 - Подключаем архивы

На этапе сборки образа переключаем апстрим репозитории на vault archive, который RH любезно держат поднятым (пока что).

#!/bin/bash

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*;
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*;
sed -i 's|# baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*;

Шаг 2 - Настраиваем дополнительные репозитории

Апстрим репозитории epel и sclo так же были перенесены в архив, но в архивных репозиториях при установке пакета epel-release устанавливаемые .repo файлы будут продолжать смотреть на мертвый апстрим, так что ручками кладем файлы по пути /etc/yum.repos.d/.

[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
baseurl=https://archives.fedoraproject.org/pub/archive/epel/7/$basearch
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
metadata_expire=never

[epel7-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
baseurl=https://archives.fedoraproject.org/pub/archive/epel/7/$basearch/debug
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=0
metadata_expire=never

[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
baseurl=https://archives.fedoraproject.org/pub/archive/epel/7/SRPMS
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=0
metadata_expire=never

[centos-sclo-rh]
name=CentOS-7.9 - SCLo rh
baseurl=https://vault.centos.org/centos/7.9.2009/sclo/$basearch/rh/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-SCLo

[centos-sclo-sclo]
name=CentOS-7.9 - SCLo sclo
baseurl=https://vault.centos.org/centos/7.9.2009/sclo/$basearch/sclo/
gpgcheck=0
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-SCLo

*** ПРОДОЛЖЕНИЕ В КОММЕНТАРИЯХ ***

Как же круто, когда с обновлением Gnome стягивается новый монитор! Очень приятно 😍

Поздравьте меня с малварой на сервере!

Давно ничего не писал, не было ни идей, ни времени, но вот теперь есть повод. (идеи тоже есть, но о них позже).

Недавно я получил первый патент, принимаю поздравления. Сам патент TLDR, да и технический-юридический язык нечитаемый, поэтому вкратце о том, что было придумано и запатентовано.

Так как я являюсь разработчиком EDR, приходится иметь дело с сотнями тысяч событий в минуту, а иногда в несколько секунд. Далеко не все события можно логически отсеять просто не собирая, так как они попадают в логическую группу событий, которую нельзя исключать. Чаще всего это спам от забикса, кубера, баз данных и прочего серверного софта, который делает уж очень много того, что так же может делать и любой другой процесс. Само собой серверная часть такое количество событий тоже не очень любит, так как их приходится хранить, индексировать, обрабатывать детектирующей логикой и так далее. Да и у бекенда к тому же таких хостов не одна сотня тысяч. Приходится выкручиваться.

Когда-то давным-давно мы использовали JSON как формат событий, с ним было много проблем, но главной была то, его нужно парсить. Потом перешли на protobuf, который тоже нужно парсить, но делать это можно кратно быстрее. Храним мы все события в БД, которая поддерживает KQL и тут до меня дошло, что и protobuf из запросов KQL имеют AST, которые можно друг на друга наложить и тут понеслось. Что если выполнять фильтрацию событий по KQL выражениям прямо в рантайме и до того, как событие будет отправлено на сервер?

Сначала я написал свой KQL движок, который выдавал правильное логическое дерево запроса (их много, на наличие своего были причины), а потом начал оптимизировать выполнение. Так появилось кеширование по путям и по значением, затем своеобразная JIT оптимизация за счет перестроения дерева по горячим местам, а следом мой коллега Максим придумал перегонять выполнение в байткод и JIT-ить его!

Очень хочу написать обо всем подробно, так что если интересно, то ставьте 👍 (или не ставьте, а я всё равно напишу).

Посмотреть на патент можно по ссылке

Сходил на этот ваш, как его... Хайлод++

Впечатления смешанные, особенно если брать во внимание ценник за билет за 100к. Очень много докладов было либо про склеивание в разном порядке разных баз данных и готовых решений, либо сводилось к "не пишите HTTP запросы в контексте транзакции". В общем, после первого идти на второй уже не хотелось. И да, я понимаю, что это не мой профиль, но, как мне кажется, не обязательно заниматься делом, чтобы о нем было интересно слушать, так как интерес вызывает не сам технологический стек, а человеческая идея, мысль, интеллектуальный труд. А тут рассказывают то, что может посоветовать GPT и гугл.

Но это всё про первый день (с исключениями), но вот второй! В общем, просто оставлю здесь сочные доклады, на которых удалось побывать и какие-то свои мысли.

- Как понимание работы RAM ускорило на 30% пакетный шлюз 4G/5G-сетей и позволило обрабатывать 4M пакетов в секунду на одном ядре и 100 Gbps на NUMA node. Это просто превосходный доклад, такие работы вдохновляют. Человек показал, как скрупулезная отладка, простая (нет) prefetch инстукция, выравнивание по кешлайнам и алгоритмы могут без всяких там корутин распараллелить обработку данных на одном ядре. Результат - ускорение работы там, где я бы даже не подумал, что можно ускориться. Рецепт не универскальный, но запомнить стоит: берем профайлер (Intel vTune), смотрим количество тактов CPU на горячем месте, которые потерялись во время трансляции адресов из-за DRAM cache miss, делаем prefetch перед обращением к памяти, выравниваем всё по кешлайнам и наслаждаемся. Кстати, там был еще похожий доклад от гарды, они решали ту же задачу, но ускорялись за счет векторных инстукций.
- Хайлоад на ровном месте. Крутой доклад для чайников вроде меня, которые знать не знали как работать с БД нормально, прям гайдлайн по "бест практис". Подача спикеров отменная, даже немного театральная (хотя кому-то 100% пришлось не по вкусу), было интересно.
- Поймай меня, если сможешь: эффективный поиск региона, к которому принадлежит точка. Вот тут было прикольно заняться ментальной гимнастикой и помять мозги над задачей, с которой в жизни бы не столкнулся. Честно говоря, у меня есть сомнения в "максимальной эффективности" представленного. Осталось ощущение "недоделанности", есть мысли, как сделать быстрее. Но вот следить за ходом мысли спикера нравилось, да и задача интересная (по крайней мере для меня).
- Perforator: всеядный распределенный профилировщик. Вкуснятина, а не доклад. В отличии от всех докладов яндекса про склеивание очередной кафки с YDB и чего-то там еще, тут рассказывалось про что-то принципиально новое. Ребята придумали как снимать perf в промышленных масштабах без сильного влияния на производительность приложений и системы. Под всё это дело они запрягли eBPF, придумали свой DWARF (доработали GSYM), символизатор... и там вообще много всего. Советую ознакомиться с продуктом. А еще они там еще статью написали, которая по факту и есть весь доклад, тоже очень рекомендую (меня купили за футболку). Так же рад, что лично получилось немного пообщаться с парнями, они реально крутые,

Это не всё, что мне понравилось, а лишь то, что хотелось бы выделить. Стоило ли платить 100к (моей компании) за ~30% КПД - вопрос. Может, просто реально не мой профиль. С другой стороны для меня это как минимум свежий воздух, так как в основном я варюсь в ИБ. Да, я узнал что-то новое, да, эти знания уникальны в своем роде и вряд ли бы я на них наткнулся в готовом виде, и да, я могу их применять, но тот факт, что их приходилось искать с лупой на профильной конфе немного расстраивает. Как пример я тут вставлю SysConf, где сложность информации и ее крутость в каждом докладе была в среднем сильно выше медианы на хайлоде. Я уж молчу про ламповость самой конфы.

В любом случае, полученному опыту рад.

В целом, тут всё то же, что и в тексте патента, но человеческим языком. Рассказываю, как работает KQL фильтр в нашем продукте.

Затравочка: это не единственный патент. Остальные в процессе регистрации и рассказывать я о них не могу. Там тоже крутые технологии, которые мы применяем для работы с большими потоками данных. В ближайшее время, надеюсь, о них тоже получится рассказать :)

UPD:
Затравочка 2: больше крутостей вокруг этой технологии я планирую рассказать на конференции уже в следующем годy. Будет мясо.