Ctrl + C (управляющий символ intr
): Он отправляет сигнал SIGINT
процессу, и обычно приложение прерывается, но приложение может обработать этот сигнал. Например, вы можете обрабатывать сигнал с помощью функции signal ()
на языке C
.
Ctrl + Z (управляющий символ susp
): Он отправит сигнал SIGTSTP
процессу, чтобы перевести его в фоновый режим и как SIGINT
, это можно обработать.
Процесс не будет немедленно завершен с помощью Ctrl + C , если у него есть ожидающий ввод-вывод, и вам нужно дождаться завершения его ввода-вывода, а затем приложение завершится с объем памяти.
Но Ctrl + Z приостановит ваш процесс и его операции ввода-вывода. Технически операционная система не будет выделять процессорное время, и если вы завершите фоновый процесс, он может потерять часть операций ввода-вывода и данные.
Для принудительного завершения процесса вы должны SIGKILL
или сигнал номер 9, который является наиболее мощным сигналом - операционная система немедленно уничтожит его, но вы можете потерять данные, так как программа не сможет реагировать на этот сигнал.
Не похоже.
$ unshare -r
# ulimit -u 1000
# sh -c 'for i in $(seq 998); do sleep 1& done' >/dev/null
sh: fork: retry: Resource temporarily unavailable
sh: fork: retry: Resource temporarily unavailable
... (i.e. more than one error - so I guess my existing processes were already counted)
sh: fork: retry: Resource temporarily unavailable
-bash: fork: retry: Resource temporarily unavailable
Аналогично:
$ unshare -r
# ulimit -u 1002
# sh -c 'for i in $(seq 100); do sleep 1& done' >/dev/null
# sleep 2
# for i in $(seq 10); do unshare -r sh -c 'for i in $(seq 100); do sleep 1& done' >/dev/null; done
sh: fork: retry: Resource temporarily unavailable
sh: fork: retry: Resource temporarily unavailable
Запуск ulimit -u 1000
внутри unshare -r
не влияет на моего пользователя за пределами пространства имен пользователя. А, -это потому, что ulimit -u
всегда устанавливает ограничение внутри процесса. Но когда лимит проверяется в fork (), мы сравниваем RLIMIT _NPROC для этого процесса с общим количеством процессов "настоящего" UID, т.е. с точки зрения "корневого" "пространство имен.
Насколько я вижу, все это работает довольно хорошо.
Между прочим, я заметил, что вы не можете использовать пространства имен пользователей для создания процессов с несколькими разными UID, если у вас нет привилегий.
$ unshare -r
# id -u
0
# setpriv --ruid 1 sh
setpriv: setresuid failed: Invalid argument
Правила для этого аспекта объясняются, например. Майкл Керриск в Пространства имен в действии, часть 5 :Пространства имен пользователей .
Существует общий принцип, согласно которому наличие пространств имен не дает вам никаких дополнительных привилегий. Нет ничего, что вы могли бы сделать с остальной частью системы с несколькими пространствами имен, чего вы не могли бы сделать с одним пространством имен. Пространства имен дают вам дополнительную возможность применять дополнительные ограничения к некоторым из ваших процессов.
RLIMIT_NPROC
— это максимальное количество процессов, которые вы можете создать. Если некоторые из этих процессов находятся в пространствах имен, у них может быть меньше привилегий, но они все равно считаются одним процессом. В любом случае все эти процессы являются процессами во внешних пространствах имен. У них могут быть разные UID внутри пространства имен, но вне пространства имен они являются вашими процессами.