Инструмент для сжатия файловой системы exFAT в автономном режиме для Linux

Вся идея, лежащая в основе podman, состоит в том, чтобы уйти от централизованной архитектуры с помощью сверх-могущественного надзирателя (, т.е. dockerd), где централизованный демон является единственной точкой отказа. Об этом даже есть хэштег -"# nobigfatdaemons ".

Как избежать централизованного управления контейнерами? Вы снова удаляете единственный основной демон (,dockerd) и запускать контейнеры независимо (в конце дня, контейнеры — это просто процессы, поэтому вам не нужен демон для их порождения ).

Тем не менее, вам все еще нужен путь к

  • собрать логи контейнера -кто-то должен держать stdoutи stderrконтейнера;
  • собрать код выхода контейнера -кто-то должен wait(2)на PID контейнера 1;

С этой целью каждый контейнер podman по-прежнему контролируется небольшим демоном, называемымconmon(от «монитор контейнера» ). Разница с демоном Docker заключается в том, что этот демон настолько мал, насколько это возможно (проверьте размер исходного кода ), и он порождается для каждого -контейнера. Если conmonдля одного контейнера дает сбой, остальная часть системы остается неизменной.

Далее, как создается контейнер?

Учитывая, что пользователь может захотеть запустить контейнер в фоновом режиме, как в случае с Docker, podman runпроцесс разветвляется дважды и только затем выполняетсяconmon:

$ strace -fe trace=fork,vfork,clone,execve -qq podman run alpine
execve("/usr/bin/podman", ["podman", "run", "alpine"], 0x7ffeceb01518 /* 30 vars */) = 0
...
[pid  8480] clone(child_stack=0x7fac6bffeef0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[8484], tls=0x7fac6bfff700, child_tidptr=0x7fac6bfff9d0) = 8484
...
[pid  8484] clone(child_stack=NULL, flags=CLONE_VM|CLONE_VFORK|SIGCHLD 
[pid  8491] execve("/usr/bin/conmon",... 
[pid  8484] <... clone resumed>)        = 8491

Промежуточный процесс между podman runи conmon(, т. е. непосредственный родительский процесс conmon-, в приведенном выше примере это PID 8484. )завершится, а conmonбудет повторно отнесен к init, таким образом став собственным -управляемый демон. После этого conmonтакже отделяется от среды выполнения (, например.runc)и, наконец, среда выполнения выполняет точку входа контейнера (, например./bin/sh).

Когда контейнер запущен, podman runбольше не требуется и может закрыться, но в вашем случае он остается в сети, потому что вы не просили его отсоединиться от контейнера.

Затем podmanиспользует контрольные группы для ограничения контейнеров. Это означает, что он создает новые контрольные группы для новых контейнеров и перемещает туда процессы . По правилам cgroups процесс может одновременно быть членом только одной cgroup,и добавление процесса в некоторую контрольную группу удаляет его из другой контрольной группы (, где он был ранее )в той же иерархии. Итак, когда контейнер запущен, окончательная компоновка контрольных групп выглядит следующим образом:podman runостается в контрольных группах baz.service, созданных systemd, процесс conmonразмещается в своих собственных контрольных группах, а процессы в контейнерах помещаются в свои собственные контрольные группы:

$ ps axf
<...>
 1660 ?        Ssl    0:01 /usr/bin/podman run --rm --tty --name baz alpine sh -c while true; do date; sleep 1; done
 1741 ?        Ssl    0:00 /usr/bin/conmon -s -c 2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6 <...>
 1753 pts/0    Ss+    0:02  \_ sh -c while true; do date; sleep 1; done
13043 pts/0    S+     0:00      \_ sleep 1
<...>

$ cd /sys/fs/cgroup/memory/machine.slice
$ ls -d1 libpod*
libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope
libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope

$ cat libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1753
13075

$ cat libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1741

Примечание. :PID 13075 выше на самом деле является sleep 1процессом, порожденным после смерти PID 13043.

Надеюсь, это поможет.

0
01.11.2021, 20:17
1 ответ

Это не имеет ничего общего с gparted и все с exfatprogs.

Пожалуйста, подпишитесь наhttps://github.com/exfatprogs/exfatprogs/issues/134

2
01.11.2021, 21:01

Теги

Похожие вопросы