… или «как перестать бояться и разбить палаточный городок аккурат на минном поле».

В общем, ни для кого не секрет, что у нас тут семимильными шагами идет возврат от богомерзкого x86 к классической паре UNIX+RISC в ее современной реинкарнации: Linux+ARM. И так уже получилось, что на этот раз заход был не со стороны рабочих станций, а со всяких маломощных мобильников и малинок. Сбоку подают голос пользователи Apple Silicon, но их пока сравнительно мало.

Одновременно с этим, армов стало достаточно много, чтобы задуматься о том, как собирать под них софт. И если раньше для этого использовали кросс-компиляцию и всякие хаки, то сейчас у нас появилась прекрасная эмуляция вида qemu-arm-static с binfmt, исполняемые на x86. То есть, достаточно сделать чрут с армовой осью, а затем сказать ядру, чтобы для запуска бинарников с сигнатурой ARM он использовал qemu-arm-static - и вуаля, ваши армовые бинарники волшебным образом начинают работать на x86 машине, как родные.

Круто? Круто. Можно зачрутиться в систему, позапускать в ней всякие pacman и dpkg, чтобы получить корень, в котором затем выполнять сборку пакетов с помощью обычных makepkg, debuild и других дистротулов. Здорово? Здорово. И наплевать, что это медленнее кросс-сборок, потому что в разы проще и не требует от всего софта поддерживать префиксы для фейкового корня. А еще можно нативно повыполнять какие-то команды внутри чрута, чтобы получить корень, который затем можно скопировать на карту памяти вашего армового эмбеда.

Сейчас у нас есть как минимум два широко рапространенных инструмента для сборки чего-либо в эмуляции:

• docker-buildx. Это такой docker-build на стероидах, который в том числе поддерживает сборку докер-образов для ARM (и других архитектур) на x86. Как? С помощью QEMU и binfmt, разумеется.
• pi-gen с опцией USE_QEMU=1. Это официальная тулза для сборки образов Raspberry Pi. Суть почти та же: команды выполняются в чруте, чтобы получить образ для карты памяти.

Эти вещи удобны тем, что вы выполняете команды внутри вашей армовой ОС, как если бы работали непосредственно на ней. Особенно удобен докер, потому что докерфайл - это готовая документация по воспроизведению образа системы (при соблюдении определенных условий, но не суть).

В обоих случаях QEMU играет ключевую роль. И всё бы было хорошо, но он иногда падает. Либо сегфолтится, либо вылетает в какой-нибудь ассерт - разницы нет, суть в том, что эмуляция прерывается. Увы, но мой опыт активного использования qemu-arm-static показывает, что баги в нем хотя и фиксятся, но имеют свойство либо возвращаться с очередным мажорным релизом, либо что-то в ранее работающих воркфлоу может сломаться в новом неожиданном месте. Я не большой спец по QEMU, но таки делал репорты. Что-то исправлено, а что-то открыто до сих пор. Что хуже - поведение QEMU часто зависит от настроек хостовой ОС, и то, что вылетает на арче, не будет вылетать на дебиане.

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

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

А вот нет.

Берем типичный сценарий современного использования QEMU - docker-buildx. В докерфайле у нас есть несколько команд RUN, которые выполняют всякие установки пакетов и прочие операции. А что происходит при установке пакетов, помимо распаковки и размещения файлов? Правильно, запускаются всякие хуки на баше. Спаунится пакетный менеджер, из него спаунится баш для скрипта, а из скрипта поочередно спаунятся команды. Коды возврата которых, разумеется, никто не проверяет. Ведь вряд ли у вас из под руда упадет какой-нибудь ls /, верно? Или, скажем, греп.

Но с QEMU они падают.

Вот что вы можете увидеть в эмуляции, пытаясь поставить пакет:

:: Proceed with installation? [Y/n]
:: Retrieving packages...
 openssl-3.1.4-1-aarch64 downloading...
 openssl-1.1-1.1.1.w-1-aarch64 downloading...
checking keyring...
checking package integrity...
loading package files...
checking for file conflicts...
:: Processing package changes...
upgrading openssl...
installing openssl-1.1...
error: command terminated by signal 11: Segmentation fault
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

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

Внутри пост-инсталл хука происходит сегфолт, но поскольку почти никто не ставит в скриптах set -e и не проверяет код возврата тривиальных (ха-ха) операций, установленный пакет будет находиться в неопределенном состоянии. И сборка будет продолжаться, потому что код возврата всего скрипта был нулевой! Пакет вроде поставлен, но корректно ли?

Эта проблема касается не только pacman и dpkg, но и вообще любых шелл-скриптов. Кто вообще может гарантировать, что во всех этих килопарсеках портянок, запускающихся в эмуляции, не будет вот таких непредсказуемых сбоев, на которые никто и никогда не делал тесткейс, потому что они, по мнению авторов скриптов, не могут сбойнуть?

Самое страшное тут то, что docker-buildx и сборки образов через QEMU сейчас получили повальное распространение из-за своей простоты. Вокруг нас может быть уже полно устройств с ОС, поломанными еще на этапе сборки. К чему это может привести - время покажет. Как минимум - к сложно детектируемым ошибкам у конечного пользователя.

Ну и самый интересный вопрос: хто виноват?

• Ну, в меньшей степени виноват QEMU. Это отличная утилита, которая просто делает свою работу. Она не виновата в том, что ее начали использовать в настолько комплексных окружениях. В некоторых ситуациях она сегфолтится, в других - сознательно падает с какой-то диагностикой. Это лучшее поведение, какое только можно придумать в этом случае.
• docker-buildx? На своем уровне он тоже делает, что может.
• Баш-портянки? Пожалуй, они. Точнее, общая низкая культура их кода. Коды возврата не проверяются, фейлы пайпов не проверяются. Кушаем, как есть.
• А может, виноваты диды? В своей бесконечной мудрости отцы UNIX сделали шелл, который ведет себя как сишечка: когда ты хочешь выстрелить себе в ногу, тебе услужливо подают патрон и усаживают в кресло. Ничто не мешало сделать неявную проверку кода возврата и выход из скрипта с ошибкой, и требовать явно эту ошибку игнорить при необходимости. Они предполагали, что этим будут пользоваться люди, которые знают, что делают, но теперь, спустя сорок лет, мы имеем в скриптах повальный чад кутежа.

А шо делать-то?

А ничего. Исправить все скрипты в мире не представляется возможным. Слепая установка set -e или ее аналоги на более низком уровне может привести к другим проблемам. Остаются два пути:

• Использовать чистые кросс-сборки без эмуляции, как делали другие мудрые диды (мое почтение NetBSD c их тулчейном).
• Использовать сорта чрутов (включая докер), но на реальном железе, а при нехватке производительности - подключать distcc.

В обоих случаях теряется удобство связки docker+QEMU, но за это удобство мы платим прямо сейчас щелчком взрывателя под жопой.

Что-то, короче, скучно мне стало, и решил я прикупить какого-нибудь старого железа, чтобы поиграться. Окунуться, так сказать, в былое, во времена православных юниксов и легендарных архитектур. Что мне пока пришло в голову:

• Какой-нибудь довольно древний SPARC, типа Sparcstation ITX. Накатить солярочки, попробовать прицепить к интернету, вот это всё. Мне просто нравится продукция SUN - она какая-то душевная что ли, самобытная такая.
• Чуть более новую приблуду, типа SUN Ultra. Под него вроде бы даже какие-то линуксы есть. Кто-нибудь на лоре еще гоняет их, хотя бы из спортивного интереса?
• Какой-нибудь DEC Alpha. Если честно, ничего о них не знаю и живьем не видел.
• Ваша опция?

Короче, лор. Поделитесь, какие вы знаете красивые визуально и/или архитектурно железки из древних времен? Чем они вам нравятся? Что можно такого купить, чтобы попробовать, не знаю, сервер там собрать да домашнюю страничку захостить, или просто поиграться со старой оболочкой. Ну и отдельный вопрос, что из современного софта на этом всё еще может работать.

Сап. Есть линукс. Есть два демона. Один (сервер) генерирует поток картинок (видео) в виде кучи raw-данных и кладет их в shared memory. Второй демон (клиент) читает эти картинки и что-то с ними делает. Проблема стара, как мир: нужно сделать синхронизацию, чтобы клиент не читал неконсистентные данные, пока сервер их обновляет.

Очевидное решение - использовать posix-семафоры, но с ними есть проблема. Если какой-либо из процессов сдох, не вернув значение в семафор, то при после респауна оба демона встанут раком и будут ждать значение, которого ни у кого нет.

Код тут.

Вопрос: как организовать межпроцессную блокировку так, чтобы она снималась, если процесс сдох?

Менее очевидное решение - сделать таймаут взятия семафора на сервере. Если попытка взять семафор длится больше секунды, то вероятно клиент сдох и можно считать, что семафор взят. Здесь есть логичная проблема: если клиент не сдох, а просто тормозил по неизвестной причине, то в какой-то момент он вернет свое значение и семафор вместо значений 0 и 1 будет использовать 1 и 2.

Другое решение - использовать SysV-семафоры, у которых есть SEM_UNDO. Не нравится требованием иметь какой-то файл на файловой системе. И вообще, нет ли подводных камней с SEM_UNDO?

Альтернатива - flock на файл. Не подходит отсутствием таймаута (клиенту важно).

Пните в нужном направлении пжалста. Можно только линукс-решение, переносимость на бсд* и прочее не интересует.