Как работает утилита ulimit -u <ограничение>?

[жучара]

Друзья!
man bash, там поиск ulimit -u

-u Максимальное количество процессов для одного пользователя

Всё. Какого пользователя, почему пользователя- непонятно. И практика ответов на эти вопросы не даёт.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Предполагаю, что тот пользователь имеется ввиду, который команднул ulimit -u <ограничение>. Ну так ограничим сами себя в количестве процессов.

Всего процессов 186 (это В СИСТЕМЕ, не в консоли)

Shell

user@astra:~$ ps -eal | wc -l
186
user@astra:~$

-----------------------------------
Из них юзеру принадлежат 32 процесса

Shell

user@astra:~$ ps -u user | wc -l
32
user@astra:~$

-----------------------------------
А создать он может аж тыщу.

Shell

user@astra:~$ ulimit -u
1000
user@astra:~$

-----------------------------------
Уменьшим это количество до сотни

Shell

user@astra:~$ ulimit -u 100
user@astra:~$
user@astra:~$ ulimit -u
100
user@astra:~$

-----------------------------------
И создадим процесс:

Shell

user@astra:~$ ps
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: Ресурс временно недоступен
user@astra:~$

Напомню, всего user создал 32 процесса, а создать может аж 100. Похоже, это ложь. И такой вот вывод при других командах, например bash

Shell

user@astra:~$ bash
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: retry: Нет дочерних процессов
bash: fork: Ресурс временно недоступен
user@astra:~$

Число 100 непостоянное, иногда это 120, иногда 140. 100 взял для красоты. Я понимаю, там вспомогательные процессики могут создасться, но не 70 же штук.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

На всякий случай: user в системе это один пользователь (UID=1000), который настоящий пользователь. Остальные- root и прочие системные кто они там не знаю.

Shell

user@astra:~$ ps -eal --sort=uid | awk '{ print $3 }' | uniq
UID
0
1
13
33
102
103
104
108
109
115
116
1000
user@astra:~$

В общем, грустно от всего этого и разобраться не знаю как. Спасибо, кто откликнется.

[serzh-z]

Конечно же вам все лгут...

Всё. Какого пользователя, почему пользователя- непонятно.

ulimit выставляет ограничения для текущего процесса оболочки и это ограничение наследуется всеми дочерними процессами. А пользователь - тот который ассоциирован с процессом.

[жучара]

ulimit выставляет ограничения для текущего процесса оболочки и это ограничение наследуется всеми дочерними процессами. А пользователь - тот который ассоциирован с процессом.

если это так, то процесс-то почему не запускается? В наличии 32 процесса, возможно 100. 33-ий не запускается. 33 не 100 ведь. Тут до ограничения как медному чайнику до ржавчины.

[serzh-z]

жучара
Ограничение работает на количество дочерних процессов для текущего процесса.

[жучара]

Ограничение работает на количество дочерних процессов для текущего процесса.

ну хорошо. А процесс-то почему не запускается? Он же должен запускаться, ограничение же ещё не сработало. 33-ий процес же не сотый.

[Bizdelnick]

А процесс-то почему не запускается?

Неправильно посчитали. Более точное описание надо смотреть в man setrlimit. Во-первых, в linux подсчитываются не процессы как таковые, а потоки, во-вторых, они отбираются не по эффективному, а по реальному идентификатору пользователя, и в-третьих, строку заголовка надо убрать. То есть надо смотреть ps -L -U user --no-headers | wc -l

[жучара]

Ну вот видите, процессы и потоки- совсем разные вещи, то есть абсолютно. В man getrlimit сей факт упомянут, да.

RLIMIT_NPROC
Максимальное количество процессов (или, более точно для Linux, нитей),

Или более точно... Ну. Бог им судья.

К man getrlimit если добросовестно отнестись, так свою прогу писать надо типа:

Код: Выделить всё

       #define _GNU_SOURCE
       #define _FILE_OFFSET_BITS 64
       #include <stdio.h>
       #include <time.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <sys/resource.h>


       int main()
       {
           struct rlimit old_new;

	   
	   prlimit(0, RLIMIT_NPROC, NULL, &old_new);
	   printf ("%d   %d\n", old_new.rlim_cur, old_new.rlim_max); 

	   //меняем значение если количество потоков больше 200
	   if   (old_new.rlim_cur > 200)
	   {
	      old_new.rlim_cur = 200;
	      prlimit(0, RLIMIT_NPROC, &old_new, NULL);
	      printf ("%d   %d\n", old_new.rlim_cur, old_new.rlim_max); 
	   }

	   return 0; 
      }
	 

Предполагается, что читающий сие умный. Но не до такой же степени. Обыкновенный чел, не знакомый с Си, обескуражится. Вот тебе и линукс. подумает он.
Лазейку в man getrlimit всё же оставили:

Ограничения ресурсов интерпретатора командной строки можно устанавливать с помощью встроенной команды ulimit

++++++++++++++++++++++++++++++++++++++++++++++++++++++++

А вот что интересно, первый параметр у функции prlimit - PID процесса. Я попробовал передавать туда PID bash-а (НЕ ДОЧЕРНЕГО К ВЫЗЫВАЮЩЕМУ ПРОЦЕССУ!), так его значение ulimit -u менялось на указанное. Вот это да. Если традиционным способом устанавливать количество процессов (ulimit -u) то ограничение будет действовать только на текущий и дочерние процессы. Там даже возможности нет никакой указать PID

Получается, они всё это дело ради такой возможности и замутили- устанавливать ограничения не только для вызывающего процесса и для дочернего процесса, но и для других.

[/dev/random]

Ну вот видите, процессы и потоки- совсем разные вещи, то есть абсолютно.

В Linux потоки - это разновидность процессов. Процессы, разделяющие память друг друга, таблицу открытых файлов и прочие параметры, а также запускающие новые процессы от имени родителя, а не от своего. При желании, при создании нового процесса все эти параметры можно включать и выключать индивидуально.

[жучара]

Просто для полноты картины. prlimit - хорошие возможности. Позволяет поднимать жёсткие (а следовательно, и мягкие) ограничения для стороннего работающего процесса из-под sudo

C помощью unlim (например unlim -u) можно поднять мягкие ограничения ОДИН раз, при самом первом использовании. После чего жёсткие ограничения приравниваются к мягким.