Почему unshare -p не подразумевает -f и --mount-proc?
В bash вы бы использовали
#!/usr/bin/env bash
read -p 'Type text: ' userInput
printf 'Your input was %d chars long\n' "${#userInput}"
Количество строк можно получить с помощью ${#var}. Использование wcв этом случае не нужно
Пространства имен Linux создаются с помощьюunshare(2)системного вызова . Программаunshareпредставляет собой просто тонкую оболочку системного вызова unshare(2), которая раскрывает функциональность пространства имен способом, который остается таким же гибким, как и базовый системный вызов.
Для большинства пространств именunshare(2)изменяет среду выполнения вызывающих процессов, отделяя ее от родительского пространства имен и связывая ее с новым, обычно пустым пространством имен. Например, процесс, который удаляет себя из сетевого пространства имен , сразу же видит новое, пустое сетевое пространство имен без устройств.
Однако пространство имен PID работает иначе. Когда unshare()вызывается для отсоединения пространства имен PID, он не изменяет среду выполнения вызывающих процессов, а вместо этого заставляет дочерний процесс после fork()входить в новое пространство имен pid и получать PID 1 в новом пространстве имен. PID 1 зарезервирован для процесса init.
Вероятные причины, по которым --forkи --mount-procне являются параметрами по умолчанию:
--forkскорее всего не является значением по умолчанию, так как никакое другое пространство имен не требует ответвления , и наличие--forkв качестве отдельной опции сохраняет поведение опции--pidв соответствии с тем, как другие опции пространства имен отображаются напрямую наunshare(2)флаги.--mount-proc, скорее всего, не используется по умолчанию, так как подразумевает пространство имен монтирования (--mount), и аналогично--forkвыполняет дополнительные действия помимоunshare(2)с соответствующими флагами.
Для правильного использования пространств имен PID требуется специальная программа, специально предназначенная для выполнения роли initв новом пространстве имен. Внутри нового пространства имен PID процесс с pid1 имеет три уникальные особенности по сравнению с другими процессами:
1 )Он автоматически получает обработчики сигналов по умолчанию. Это означает, что сигналы, отправленные ему, игнорируются, если процесс явно не регистрирует обработчики сигналов.
2 )Если другой процесс в пространстве имен умирает до того, как его дочерние элементы, его дочерние элементы будут преобразованы в процесс с pid 1. Это позволяет initсобирать статус выхода из процесса, чтобы ядро могло его удалить. из таблицы процессов.
3 )Если процесс с PID 1 умирает, все остальные процессы в пространстве имен pid будут принудительно завершены, а пространство имен уничтожено.
По этим причинам прикладные процессы обычно не подходят для запуска от имени PID 1 в пространстве имен PID.
Добавление пространств имен для различных ресурсов, управляемых ядром, было в первую очередь мотивировано технологией контейнеров , в частности системными контейнерами , которые предлагают среду, очень похожую на обычные виртуальные машины(VMS ), но без накладных расходов, связанных с запуском отдельного ядра, имитирующего аппаратное обеспечение для виртуальных машин. Ранее, когда пространства имен были представлены в ядре Linux (, в основном между Linux 2.4.19 -3.8 ), пространства имен PID были введены после пространств имен Mount, UTS, IPC и Network. Ранние версииunshareсоздали прецедент того, как должны были вести себя различные параметры пространства имен.
До появления полноценных -инфраструктур контейнеров, таких как LXC и Docker ,unshareможно было использовать в качестве импровизированной утилиты для запуска демона init(. ] напримерsystemd)внутри нового контейнера (, состоящего из нового пространства имен PID и, возможно, других неразделяемых пространств имен ). Такие фреймворки включают в себя собственный функционал для запуска контейнеров без необходимости unshare. Современные версииsystemdтакже поддерживают эту функцию без необходимости использования отдельной утилиты unshare.