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.