Nie można przełączyć, ssh na konkretnego użytkownika: su: nie można ustawić identyfikatora użytkownika: Zasób chwilowo niedostępny?


15

/var/log/secure:

su: pam_keyinit(su-l:session): Unable to change UID to 500 temporarily
su: pam_keyinit(su-l:session): Unable to change UID to 500 temporarily
su: pam_unix(su-l:session): session opened for user adtech by root(uid=0)
su: pam_unix(su-l:session): session closed for user adtech

Wydaje mi się, że jest to spowodowane limitem na użytkownika, ale nie różni się to w porównaniu z innym użytkownikiem.

Oto ulimit -ndla adtech:

[adtech@hmaster87 root]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 192025
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 655360
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

i ten dla quanta:

[quanta@hmaster87 ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 192025
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 655360
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

liczba procesów uruchomionych przez adtech:

[root@hmaster87 ~]# ps -U adtech | wc -l
25

Masz jeszcze coś do sprawdzenia?


AKTUALIZACJA Sobota 21 lipca 09:21:26 ICT 2012:

# getent passwd adtech
adtech:x:500:502::/home/adtech:/bin/bash

Jak powiedziałem w poniższym komentarzu, mój współpracownik odkrył proces, który może być winowajcą:

adtech 12901 1 0 08:58 ? 00:00:00 /home/adtech/nexus/bin/../bin/jsw/linux-x86-64/wrapper /home/adtech/nexus/bin/../bin/jsw/conf/wrapper.conf wrapper.syslog.ident=nexus wrapper.pidfile=/home/adtech/nexus/bin/../bin/jsw/linux-x86-64/nexus.pid wrapper.daemonize=TRUE

adtech 12903 12901 1 08:58 ? 00:00:24 java -Dsun.net.inetaddr.ttl=3600 -DbundleBasedir=. -Djava.io.tmpdir=./tmp -DjettyContext=nexus.properties -DjettyContextIncludeKeys=bundleBasedir -DjettyPlexusCompatibility=true -Djava.library.path=bin/jsw/lib -classpath bin/jsw/lib/wrapper-3.2.3.jar:./lib/plexus-classworlds-2.4.jar:./conf/ -Dwrapper.key=ejxHaBJASiFkAB8w -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.pid=12901 -Dwrapper.version=3.2.3 -Dwrapper.native_library=wrapper -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 org.codehaus.plexus.classworlds.launcher.Launcher ./conf/jetty.xml

Zabicie tego procesu rozwiązuje problem, ale nadal nie wiemy, który limit został przekroczony.


AKTUALIZACJA Sobota 15 grudnia 00:56:13 ICT 2012:

Odpowiedź @ favadi jest prawidłowa, ale aktualizuję tutaj na wypadek, gdyby ktoś google znalazł w tym wątku.

Plik dziennika powiedział, że:

jvm 1    | Server daemon died!
jvm 1    | java.lang.OutOfMemoryError: unable to create new native thread
jvm 1    |      at java.lang.Thread.start0(Native Method)
jvm 1    |      at java.lang.Thread.start(Thread.java:640)
jvm 1    |      at org.tanukisoftware.wrapper.WrapperManager.privilegedStopInner(WrapperManager.java:3152)
jvm 1    |      at org.tanukisoftware.wrapper.WrapperManager.handleSocket(WrapperManager.java:3797)
jvm 1    |      at org.tanukisoftware.wrapper.WrapperManager.run(WrapperManager.java:4084)
jvm 1    |      at java.lang.Thread.run(Thread.java:662)

Przepraszamy, jeśli jest to zbyt oczywiste, ale czy w systemie jest identyfikator użytkownika 500? Czy odnosi się do nazwy użytkownika, która będzie używać? Powodzenia.
— łupacz

Jasne, adtechużytkownik ma UID 500. Zobacz moją zaktualizowaną. Mój współpracownik odkrył proces, który jest winowajcą. Po zabiciu tego procesu problem zniknie, ale nadal nie wiemy, który limit został przekroczony: otwarte pliki nie, liczba procesów nie, może pamięć lub cokolwiek innego. jakieś pomysły?
— kwanty

Spróbuj dołączyć strace -f -p do tego procesu i szukaj ewidentnie nieudanych wywołań systemowych i tego, co próbują zrobić ...
— rackandboneman,

Odpowiedzi:


12

Możliwe, że max user processes (-u) 1024jest za niski.

Pamiętaj, że procesy i wątki liczą się razem. Możesz użyć, ps -eLF | grep adtech | wc -laby pokazać swoją aktualną wartość.


7
Dokładniej powinno być ps -eLF -U adtech | wc -l.
— kwanty

2
Jeśli zastanawiasz się, gdzie to jest ustawione, zajrzyj do /etc/security/limits.d/90-nproc.conf (zakładając, że korzystasz z systemu RH).
— mricon

@mricon sprawdzanie /etc/security/limits.d/90-nproc.confzwrotów /etc/security/limits.d/90-nproc.conf: No such file or directoryna CentOS7
— 030

@Utrecht dobrze, mogłeś zrobić „ls” w /etc/security/limits.d/ i zauważyłeś, że na EL-7 nazywa się to „20-nproc.conf”, co prawdopodobnie byłoby szybsze niż zadawanie go tutaj.
— mricon

2
@ quanta, a ściślej mówiąc, powinno być ps -LF -U adtech | wc -l. Korzystając z tej -eopcji, otrzymujesz również procesy innych użytkowników.
— Lambert

2

Poszukaj w dzienniku JVM dowodów, że osiąga on limit zasobów. Problemem może być rozmiar stosu, w zależności od liczby wątków Java, które uruchomił zabity proces.

Wyszukiwanie komunikatu o błędzie pozwala znaleźć raporty o błędach dotyczące pam_keyinit: sprawdź w repozytorium dostawcy, czy dostępna jest zaktualizowana wersja.


+1. Zapomniałem lekcji: spójrz na dziennik, gdy pojawia się problem. Zaktualizowałem moje pytanie.
— kwanty

0

Błąd został zgłoszony przez pam_keyinit. Ponieważ nie jestem zaznajomiony z tego modułu, szukałem dokumentacji i znaleźć ten manpage . Na podstawie opisu zastanawiam się, czy być może proces, który zabiłeś, uniemożliwił niezbędny dostęp do niektórych plików, które pam_keyinit musi zmodyfikować? Mam nadzieję, że to da ci pewien kierunek.


0

Ten problem może się zdarzyć, jeśli zostanie osiągnięty limit przebiegu procesu użytkownika. Limit procesu można zwiększyć, edytując: /etc/security/limits.confplik z uprawnieniami użytkownika root. Wpis do sprawdzenia będzie podobny do:

*          hard     nproc         100

Nie trzeba ponownie uruchamiać żadnych usług.


1
W moim przypadku podniesienie twardego limitu nie miało natychmiastowego skutku; Musiałem zmienić miękki.
— Nicola Musatti
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.