Потокобезопасность system(3) в glibc

Какое вопиющее неуважение к Ъ….

Ужос!

… а musl мне никогда не нравилась, особенно, после статьи, в которой описывалось, как запросы в mysql под musl работали на одинаковом датасете не таким же образом, как на glibc.

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

Спасибо, интересное чтиво.

Так что я зарепортил баг относительно лакуны в документации musl:

https://github.com/somasis/musl-wiki/issues/63

Красавец, теперь зарепорть не в рандомный багтрекер, а в список рассылки musl, как потребовано.

Самый большой грех system в том, что она не ищет в $PATH. Следующий — в том, что шеллы там у всех разные. Третий по величине — что создаёт круговую зависимость между шеллом и libc. Не юзайте эту дрянь.

Красавец, теперь зарепорть не в рандомный багтрекер

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

Ну и чтоб два раза не вставать, про sed написал:

https://wandrien.dev/developer-notes/2021/sed-E/

http://musl.libc.org/support.html

musl has a single mailing list for development discussion and user support. Questions and comments related to compiling musl, compiling software against musl, porting, bugs, differences between musl and glibc or other libc implementations, feature requests, etc. are all on-topic and welcome.

Теперь давай свой пруф.

https://wiki.musl-libc.org/

You can contribute to this wiki! Submit pull-requests to somasis/musl-wiki.

А по сути, дурак ты и не лечишься. Нормальные люди либо сотрудничают при наличии общего интереса, либо просто не трогают друг друга. Тебе же нужно до всех докопаться с какой-то хернёй.

Автор, спасибо.

Чел, ты проиграл, это community wiki, а ни разу не обещанная тобой ссылка с официального сайта. Если у тебя была цель поныть в месте, чуть релевантнее ЛОРа, то ты, конечно преуспел. Но лучше зарепорть баг как полагается.

зачем ты так много внимания уделяешь работе софта на других системах *nix? все эти системы фактически давно мертвы, только линукс остался

Самый большой грех system в том, что она не ищет в $PATH. Следующий — в том, что шеллы там у всех разные. Третий по величине — что создаёт круговую зависимость между шеллом и libc. Не юзайте эту дрянь.

Ерунда от начала до конца. system вызывает /bin/sh -c «аргумент». Соответственно, в $PATH ему искать нечего. /bin/sh задан уже с путём (и там должен быть posix shell а не разное у всех), а аргумент - это команда для шелла, интерпретирует её шелл а не system. И зависимости никакой нет.

Ерунда от начала до конца. system вызывает /bin/sh -c "аргумент".

Да. Путь к бинарнику везде константа, и нет никакого смысла использовать там $PATH.

Пойнт про то, что шеллы везде разные, тоже нерелевантен. На POSIX-совместимой системе шелл должен быть POSIX-совместимым. А на несовместимой, извините, как получится. В DOS это COMMAND.COM, в винде при использовании нативного рантайма от MSVC это CMD.EXE.

Ерунда от начала до конца. system вызывает /bin/sh -c «аргумент». Соответственно, в $PATH ему искать нечего. /bin/sh задан уже с путём (…), а аргумент - это команда для шелла, интерпретирует её шелл а не system.

Ну, это ясное дело.

И зависимости никакой нет.

Есть. Нет /bin/sh — твой system сломан. => libc зависит от шелла

и там должен быть

Не должен, все well-known пути — зло.

posix shell а не разное у всех

В Alpine — ash, в Debian — dash, в Fedora — bash…

Путь к бинарнику везде константа

Да. Благодаря этому историческом идиотизму я могу одновременно юзать сколько угодно libc, но шелл для system это теперь святое и единое для всех.

Благодаря этому историческом идиотизму я могу одновременно юзать сколько угодно libc, но шелл для system это теперь святое и единое для всех.

Если ты можешь юзать разный libc, то и константу в нём при компиляции на свою заменить можешь.

/thread

В Alpine — ash, в Debian — dash, в Fedora — bash…

Это всё POSIX shell.

А я и меняю, и кляну каждый раз и всю доисторическую «установлено в системе» ментальность, и конкретно лентяев-написателей идиотского стандарта, захардкодивших там круговую зависимость вообще безо всякой хорошей на то причины.

Это все несовместимый по-разному бажный POSIX Shell который больше не заморозить средствами пакетного менеджера.

Это все несовместимый по-разному бажный POSIX Shell

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

который больше не заморозить средствами пакетного менеджера.

Не распарсил.

Есть. Нет /bin/sh — твой system сломан. => libc зависит от шелла

Нет. Он не сломается, он штатным образом будет отдавать ошибку. Точно так же как open(«/non-exist/1/2/3») тоже выдаст ошибку, но не от того, что сломан open() а от того, что он должен выдавать ошибку при попытке открыть несуществующий путь.

В Alpine — ash, в Debian — dash, в Fedora — bash…

Это разные реализации одного и того же. Но вообще это всё не суть. system(arg) это алиас к fork()+exec(«/bin/sh»,"-c",arg)+wait(). И именно в этом его назначение. /bin/sh это просто строка, передаваемая системному вызову execve(), в состав спецификации libc спецификация шелла не входит.

Что ты вообще такое делаешь через несчастную system(3), что у тебя лезут баги шеллов? Единственное полезное её предназначение это запустить скрипт в более другом шелле.

Я могу написать nix run… и получить произвольное окружение с любым набором софта любых версий на любой момент времени. Кроме ядра, потому что сложно на лету сменить ядро, и, блин, драного /bin/sh, потому что см выше, что я о них думаю.

А я и меняю

Зачем?

безо всякой хорошей на то причины.

Причина очень простая - дать простой проге на си короткий, в одну команду, способ запуска команд шелла, когда программист хочет просто по-быстрому запустить команду и ни о чём не думать. Такое использование си в качестве скриптоязыка. Если прога сложная, то там system() вряд ли будет использоваться, почти наверняка будет использоваться кастомная конструкция из fork+execve+wait и ещё кучи функций в середине, которые в system никак не вставить.

system() — это самый минимальный интерфейс к вызову команд операционной системы, предусмотренный для hosted-реализации Си.

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

Ты от него слишком много хочешь.

Для Unix-like системы в твоём распоряжении всегда есть нормальные exec() и posix_spawn().

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

Ака сломается.

system(arg) это алиас к fork()+exec(«/bin/sh»,«-c»,arg)+wait(). И именно в этом его назначение. /bin/sh это просто строка, передаваемая системному вызову execve(), в состав спецификации libc спецификация шелла не входит.

А должен был быть к execlp или как его там и искать sh в $PATH.

Ты от него слишком много хочешь.

Я хочу от него сдохнуть, куда уж меньше?

nix run

А, никсопроблемы. Понятно. Им дали контейнеры, а они плодят помойку из овер 100500 захардкоженных путей.

Зачем?

Потому что в моем дистрибутиве не будет драного /bin/sh или драного /usr/bin/env. Все well-known пути должны отмереть, потому что без этого я не могу (без танцев вприсядку) иметь их разными для разных процессов, а значит не могу иметь и воспроизводимости.

Им дали контейнеры

My ass, ходите на своих костылях самм

Пользуется nix

Страдает

Мнекажеццо, есть некая связь.

овер 100500 захардкоженных путей.

/bin/sh, /usr/bin/env, /dev, /sys и /proc это чуть-чуть меньше, чем 100500.

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

Еще интерпретатор ELF-файлов забыл.

Это в обычном лине чуть меньше.

А в никсе где всё линкуется по путям вида a54d010860b3e9c4b8c9c282e61da5b7128c7547697151aaca36ee771d323dc9/lib/libmycoollib.so их чутка больше.

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

Кстати, я как раз либу вон щас пишу: https://github.com/sde-gui/libmypath

Задрал софт с захардкоженными путями в собственным дата-файлам. У меня в SDE уже было это пофикшено иным способом, но там слишком complicated. Надо проще и дубовее.

Понемаю. Опасная болезнь, можно потерять сон и покой. Лечитесь девками и вином, сударь.

system()

это единственный стандартный способ создать новый процесс.

Еще интерпретатор ELF-файлов забыл.

Нет ты. Интерпретатор ELF-файлов не обязал лежать по well-known пути. И в NixOS по нему и не лежит. Даже, блин, он не обязан, зато драный /bin/sh вынь да положь.

А в никсе их больше

А в никсе они как раз 100% сменные. Настолько, что меняются на каждый чих полностью прозрачно для тебя. Но ты и так в курсе, просто неумело троллишь.

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

Тоже мне открытие.

On Unix systems, there’s no reliable way for an application to retrieve a path to its own executable image or any other application-related files.

Эээ, у тебя есть libc, поддерживающая работу без /proc? Потому что dynamic loader зависит от /proc/self/exe, инфа 100%

Нет. Это не способ создавать процессы вообще. Процессы есть не везде. Реализация в юниксах - через создание процесса, да. Ну а так есть стандартное fork() для создания нового процесса.

Эээ, у тебя есть libc, поддерживающая работу без /proc? Потому что dynamic loader зависит от /proc/self/exe, инфа 100%

No idea. Я не тестировал весь зоопарк Unix-like. Что за линукс-центризм?

Но ты и так в курсе, просто неумело троллишь.

Нет ты. (с)

Если ты можешь пропатчить всё. (А в nix ты реально патчишь кучу всего при сборке - как минимум, прописываешь тьмущу констант), то точно так же ты можешь пропатчить путь к sh.

А в никсе они как раз 100% сменные.

Он прописан в бинарнике каждом в заголовке. Как шебанг для скриптов.

Эээ, у тебя есть libc, поддерживающая работу без /proc?

В FreeBSD /proc deprecated и по дефолту даже не монтируется.

Нет.

Согласен. Правильнее popen.

стандартное fork()

Он не стандартный для СИ

Что за линукс-центризм?

Ясно. Ну, короче для Linux твоя задача звучит странно, потому что мы и так сидим на крепкой игле /proc.

Если ты можешь пропатчить всё. (А в nix ты реально патчишь кучу всего при сборке - как минимум, прописываешь тьмущу констант), то точно так же ты можешь пропатчить путь к sh.

Так я и патчу, и нарушаю POSIX.

Так я и патчу, и нарушаю POSIX.

Ну и нарушай. Какая разница?

Он прописан в бинарнике каждом в заголовке. Как шебанг для скриптов.

Ну, и легко меняется штатными средствами ПМ. Или ты хочешь единые бинарники носить между системами без зависимостей как в какой-то винде? Тогда да, ты в пролёте, носить их без остального closure не выйдет.

Обидно, блин. Нарушать POSIX просто из-за недальновидности и/или лентяйства древних.

Или ты хочешь единые бинарники носить между системами без зависимостей как в какой-то винде? Тогда да, ты в пролёте, носить их без остального closure не выйдет.

А я хочу.

Я настолько обнаглел, что хочу носить бинарники между Linux и BSD-зоопарком.

и легко (и постоянно) меняется штатными средствами ПМ.

И о чем плачь Ярославны тогда?

Он не стандартный для СИ

Это к чему? В стандартной библиотеке Си вообще нет понятия процессов. Процессы есть в POSIX, там же есть и функции для работы с ними.

Я настолько обнаглел, что хочу носить бинарники между Linux и BSD-зоопарком.

Носи виртуалки, ты же любитель всяких контейнеров и прочих тяжёлых решений там, где не надо.

И о чем плачь Ярославны тогда?

Мой — о /bin/sh, который даже в NixOS захардкожен из-за драного POSIX.

Ваш — о dynamic loader’е, с которым как раз никаких проблем нет. Я тоже не знаю, зачем вы его затянули.

хочу носить бинарники между Linux

Тоже хочу переносить бинарники между Gentoo(с systemd) и Android.