Некоторые системы имеют команды для отображения полномочий файла как число, но к сожалению, ничто портативное.
zsh
имеет a stat
(иначе zstat
) встроенный в stat
модуль:
zmodload zsh/stat
stat -H s some-file
Затем mode
находится в $s[mode]
но режим, который является типом + перманент.
Если Вы хотите полномочия, выраженные в восьмеричном, Вам нужно:
perms=$(([##8] s[mode] & 8#7777))
BSDs (включая Apple OS/X) имеют a stat
команда также.
mode=$(stat -f %p some-file)
perm=$(printf %o "$((mode & 07777))"
GNU находит (от еще 1990, и вероятно прежде) может распечатать полномочия как восьмеричные:
find some-file -prune -printf '%m\n'
Позже (2001, намного позже zsh
stat
(1997) но перед BSD stat
(2002)) GNU stat
команда была представлена со снова другим синтаксисом:
stat -c %a some-file
Задолго до тех IRIX уже имел a stat
команда (уже там в IRIX 5.3 в 1994) с другим синтаксисом:
stat -qp some-file
Снова, когда нет никакой стандартной команды, лучший выбор для мобильности состоит в том, чтобы использовать perl
:
perl -e 'printf "%o\n", (stat shift)[2]&07777' some-file
Давайте поймем разницу между процессом и потоком. Согласно ссылке this,
Типичная разница заключается в том, что потоки (одного и того же процесса) выполняются в разделяемого пространства памяти, в то время как процессы запускаются в отдельных пространствах памяти.
Теперь у нас есть параметр pid_max
, который можно определить, как показано ниже.
cat /proc/sys/kernel/pid_max
Таким образом, вышеприведенная команда возвращает 32,768, что означает, что я могу одновременно выполнять в своей системе процессы 32,768, которые могут выполняться в отдельных пространствах памяти.
Теперь у нас есть параметр threads-max
, который можно определить, как показано ниже.
cat /proc/sys/kernel/threads-max
Команда, приведенная выше, возвращает мне вывод в виде 126406, что означает, что я могу иметь потоки 126406 в общем пространстве памяти.
Теперь возьмем 3-й параметр ulimit -u
, который говорит о том, что все процессы, которые может иметь пользователь в конкретный момент времени. Вышеприведенная команда возвращает мне вывод в виде 63203. Это означает, что для всех процессов, которые пользователь создал в определенный момент времени, у пользователя могут быть запущены процессы 63203.
Гипотетический случай
Таким образом, если предположить, что одновременно 2 процесса выполняются 2 пользователями и каждый процесс потребляет много памяти, то оба процесса будут эффективно использовать пользовательский лимит на процессы 63203. Таким образом, если это так, то 2 пользователя будут эффективно использовать весь размер 126406 threads-max
.
Теперь мне нужно определить, сколько процессов пользователь может запустить в любой момент времени. Это можно определить по файлу /etc/security/limits.conf
. Итак, в основном в этом файле есть 2 настройки, которые объясняются здесь /etc/security/limits.conf.
мягкий предел подобен предупреждению , а жесткий предел является реальным максимальным пределом . Например, следующее предупреждение не позволит никому в группе учеников иметь более 50 процессов, а предупреждение будет выдано на 30 процессов.
@student hard nproc 50
@student soft nproc 30
Жёсткие ограничения поддерживаются ядром, в то время как мягкие ограничения устанавливаются оболочкой командной строки.
Извините, принятый ответ - плохая информация по нескольким фронтам.
/proc/sys/kernel/pid_max не имеет ничего общего с максимальным количеством процессов, которые могут быть запущены в любой момент времени. Это, по сути, максимальный числовой идентификатор процесса, который может быть присвоен ядром.
В ядре Linux процесс и поток — это одно и то же. Они обрабатываются таким же образом ядром. Они оба занимают место в task_struct структуре данных. Поток, по общепринятой терминологии, в Linux — это процесс, который совместно использует ресурсы с другим процессом (они также будут совместно использовать идентификатор группы потоков). Поток в ядре Linux в значительной степени является концептуальной конструкцией для планировщика.
Теперь, когда вы понимаете, что ядро в значительной степени не различает поток и процесс, должно иметь больше смысла, что /proc/sys/kernel/threads-max на самом деле является максимальным количеством элементов, содержащихся в структуре данных task_struct. Это структура данных, содержащая список процессов или, как их можно назвать, задач.
ulimit — это, как следует из названия, ограничение на пользователя. Флаг -u определяется как «Максимальное количество процессов, доступных одному пользователю». Элемент task_struct содержит идентификатор uID пользователя, создавшего задачу. A пер-Счетчик uid поддерживается и увеличивается/уме умещается каждый раз, когда задача добавляется/удаляется из task_struct. Таким образом, ulimit -u указывает на максимальное количество элементов (процессов), которые один конкретный пользователь может иметь в пределах task_struct в любой момент времени.
Я надеюсь, что это прояснит ситуацию.