Я думаю, ваше предположение верно, они наследуются от родительского пространства имен. Это похоже на то, как процессы клонируют себя, используя системный вызов fork()
, а затем любые желаемые изменения должны быть применены клоном, используя обычные системные вызовы. (Включая замену текущей программы на совершенно другую, используя exec()
. fork()
+exec()
- это то, как, например, оболочка запускает другие программы, хотя эта магия обычно не видна пользователю).
Ни один из вариантов базового системного вызова unshare
не меняет этого. Поэтому я бы сказал, что ответ на ваш вопрос - нет.
http://man7.org/linux/man-pages/man2/unshare.2.html
О... это даже не аналогия! Посмотрите на флаги опций:
CLONE_NEWNET
(начиная с Linux 2.6.24)Этот флаг имеет тот же эффект, что и
clone(2)
CLONE_NEWNET флаг. Разделить сетевое пространство имен, так что вызывающий процесс перемещается в новое сетевое пространство имен, которое не является разделяется с каким-либо ранее существовавшим процессом. Использование CLONE_NEWNET требует наличия возможности CAP_SYS_ADMIN.
clone()
в основном означает fork()
.
Начиная с версии 2.3.3, вместо того, чтобы вызывать системный вызов fork() ядра. системный вызов, обертка glibc fork(), которая предоставляется как часть реализации NPTL реализации потоков, вызывает clone(2) с флагами, которые обеспечивают тот же эффект, что и традиционный системный вызов. тот же эффект, что и традиционный системный вызов. (Вызов fork() эквивалентен вызову clone(2) с указанием флагов как просто SIGCHLD.)
Если вы используете mysql Для репозиториев / Oracle следует выбрать Linux-generic
на странице Загрузить сервер сообщества MySQL для блоков AMI, а не пакетов RedHat / Fedora.
Последний раз я проверял, что AMI не запускает systemd
, отсюда и ошибка. В то время как в прошлом вы могли несколько уйти от установки пакетов RH в AMI Linux, в настоящее время с конвергенцией версий Linux на systemd
становится все труднее устанавливать сторонние пакеты в дистрибутивы, не поддерживающие systemd
.
Также сообщите об ошибке / запросе с Oracle для пакетов AMI rpm, пожалуйста.
Проверьте также, какие версии вы можете найти в репозиториях AMI, на всякий случай.
Amazon Linux не поддерживает systemd, поэтому, если для какого-либо пакета требуется сначала установить systemd, этот пакет не будет установлен.
Я бы посоветовал вам использовать CentOS или другой дистрибутив на основе RHEL, который имеет полную поддержку SystemD и, следовательно, не будет испытывать таких же проблем.
хорошо, я дал то же самое задание своему младшему, и он дал мне эту ссылку и сказал, что невозможно установить MySQL5.7 на Amazon AMI. Но я пробовал, это действительно возможно. Вы должны загрузить mysql57 -community -выпуск -el6 -11.noarch.rpm (, подходящий для ОС CentOS/RHEL 6, и установить его ). После установки выпуска сообщества, когда вы делаете
wget https://dev.mysql.com/get/mysql57-community-release-el6-11.noarch.rpm
yum install mysql-community-server -y
Вы получите версию MySQL5.7, установленную и работающую на Amazon Linux AMI
Начиная с 2017 года Amazon предоставляет совместимый пакет MySQL 5.7.
yum install mysql57-server
Если вы обновляете существующую установку MySQL 5.5, вам, скорее всего, потребуется
mysql_upgrade --force -uroot -p
хотя бы один раз, а затем остановите и перезапустите mysqld.