ulimit -n nie zmienia się - wartości Limity.conf nie ma wpływu

Próbuję podnieść maksymalną wartość deskryptora otwartego pliku dla wszystkich użytkowników na komputerze z systemem Ubuntu.

To pytanie jest poniekąd kontynuacją tego pytania.

ustawienie limitu deskryptora pliku open.conf nie jest odczytywane przez ulimit, nawet jeśli wymagane jest pam_limits.so

poza tym, że dodałem wymagane wpisy „root” w limit.conf

Oto wpisy

*               soft    nofile           100000
*               hard    nofile           100000
root            soft    nofile           100000
root            hard    nofile           100000

Linie związane z pam_limits.sozostały skomentowane we wszystkich odpowiednich plikach w /etc/pam.d/ i fs.file-maxzostały poprawnie ustawione w /etc/sysctl.conf

Jednak nadal widzę

abc@machine-2:/etc/pam.d$ ulimit -n
1024

po ponownym uruchomieniu.

Co może być problemem?

Moją domyślną powłoką jest / bin / sh i nie mogę użyć chsh do zmiany mojej domyślnej powłoki, ponieważ mój użytkownik na komputerze jest uwierzytelniany za pomocą jakiegoś rozproszonego schematu uwierzytelniania.

Miałem podobny problem, ale tylko przy logowaniu SSH. Lokalne dane logowania (przez konsolę) były zgodne z /etc/security/limits.conf.

Jak się okazało, po ustawieniu:

UsePrivilegeSeparation yes

w /etc/ssh/sshd_configpliku, następnie sshd prosi nieuprzywilejowane dziecko, aby skonfigurować środowisko env na koncie. Ponieważ to dziecko jest nieuprzywilejowane, to ustawienie pam_limits.so ustawiania górnych limitów nie miało wpływu.

Jak tylko ustawię

UsePrivilegeSeparation no

w /etc/ssh/sshd_configi odbił usługi SSH, to plik limits.conf były przestrzegane z logowania SSH.

Podejrzewam, że ulimit jest stosowany przez / etc / profile lub ~ / .bashrc. Fakt, że twój system ma skomplikowaną pamięć, potwierdziłbym, że coś nie idzie nie tak.

Potwierdziłbym również, że nie ma błędnego pliku w /etc/security/limits.d/, który jest analizowany, jak wspomniano w pam_limits (8).

Dodałbym parametr debugowania do wymaganej linii pam_limits.conf, a następnie oglądam /var/log/auth.log podczas logowania.

Jeśli twój miękki limit wynosi 1024, jaki jest twój twardy limit?

su powinien dać ci świeże, nowe logowanie do su za pomocą argumentu -l.

su -l -s / bin / bash

Powodzenia.

Na serwerze Redhat zalogowany jako root

/etc/security/limits.conf

user01  -       nofile  2048

Komenda strace zalogowana jako root

strace -o loglimit su - user01

z innym otwartym loglimitem powłoki

grep "limit" loglimit
open("/lib64/security/pam_limits.so", O_RDONLY) = 6
 ..........
 ..........
 open("/etc/security/limits.conf", O_RDONLY) = 3
 read(3, "# /etc/security/limits.conf\n#\n#E"..., 4096) = 1823
 open("/etc/security/limits.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
 setrlimit(RLIMIT_NOFILE, {rlim_cur=2*1024, rlim_max=2*1024}) = 0

W ten sposób wiem, że załadowano pam_limits i odczytano limit.conf, jeśli twoje pam_limits zostały załadowane, ale nadal widzisz inne wartości za pomocą ulimit -n, sprawdź profil powłoki, jak powiedział @etherfish

Miałem taki problem, oto co zrobiłem.

Polecenie strace wyświetli wszystkie interakcje, które proces wykonuje z bibliotekami zewnętrznymi, dzięki czemu możemy sprawdzić, czy nasza konfiguracja jest załadowana, czy nie.

Tak, jak sugerowałem powyżej:

root:/etc/pam.d$ strace -o ~/loglimit su - glaudiston
glaudiston:~$ exit
logout
root:/etc/pam.d$ cat ~/loglimit | grep limits.conf

W moim wydaniu dziennik śledzenia (strace -o log su - nazwa użytkownika) nie zawiera żadnego wystąpienia tekstu limitów, więc plik limit.conf NIE został załadowany.

Najpierw upewniam się, że pam_limits.so szuka /etc/security/limits.conf

root:/etc/pam.d$ strings /lib/security/pam_limits.so | grep limits.conf
/etc/security/limits.conf

Dlatego upewniam się, że moduł pam_limits.so jest załadowany podczas operacji uwierzytelniania do plików znajdujących się w /etc/pam.d ... na przykład w /etc/pam.d/su, dodałem:

session   required    pam_limits.so

Teraz mogę zrobić „su” dla mojego użytkownika i limity zostaną załadowane. Możesz powtórzyć krok śledzenia, aby się upewnić.

Mój linux to LFS, więc moja wina jest brakiem pam_limits.so w plikach /etc/pam.d. W innych dystrybucjach nie uważam tego za dokładnie ten problem.

Ale mam nadzieję, że to pomaga.

W moim przypadku (Centos 6.10) strace pokazał, że po ustawieniu limitu z /etc/security/limits.conf później w procesie logowania został zresetowany z /etc/security/limits.d/90-nproc.conf dla wszystkich nie Użytkownicy root:

*          soft    nproc     1024
root       soft    nproc     unlimited