Por que ulimit -u é maior que / proc / sys / kernel / pid_max?

Question

No meu sistema ulimit -u relatórios 63172 e /proc/sys/kernel/pid_max relatórios 32768 .

Por que o valor de ulimit -u é maior que o valor do kernel? Pelo que entendi, ulimit -u mostra os processos máximos que um usuário pode ter, não o sistema inteiro. pid_max deve ser todo o sistema através do kernel. Parece-me errado que ulimit -u seja maior que pid_max , isso não significaria que um usuário poderia causar PIDs se gerassem processos suficientes? Além disso, se o valor pid_max for atingido por algo que um usuário está fazendo, isso não causará a No more processes error ?

    

Answer 1

Os PIDs do envolvem-se no uso normal. Isso não é problema algum; o kernel assegura que os novos PIDs não colidam com os PIDs existentes. Nada diz que os PIDs precisam estar aumentando monotomicamente; O processo 12345 poderia facilmente fork() e ter um processo filho de 5001.

Nesse cenário, sim, um usuário poderia potencialmente usar todos os slots do processo e impedir a ocorrência de mais atividades fork() type. Se isso for um problema em seu ambiente, você precisará ajustar os valores de ulimit em /etc/security/limits.conf ou /etc/security/limits.d/*

    

Answer 2

Isso geralmente significa que o sistema ficará sem slots de processo antes que o limite do usuário seja atingido. A página man de setrlimit diz:

RLIMIT_NPROC

The maximum number of processes (or, more precisely on Linux, threads) that can be created for the real user ID of the calling process. Upon encountering this limit, fork(2) fails with the error EAGAIN. This limit is not enforced for processes that have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.

O valor de retorno de EAGAIN implica strongmente que este é um limite em encadeamentos simultâneos, e que uma vez que um filho tenha saído, um fork() subseqüente poderá ser bem-sucedido.