Ssh değiştirilemiyor: su: kullanıcı kimliği ayarlanamıyor: Kaynak geçici olarak kullanılamıyor mu?


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

Sanırım bu kullanıcı başına sınırdan kaynaklanıyor, ancak başka bir kullanıcıyla karşılaştırıldığında farklı değil.

Here're ulimit -niçin 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

ve bunun için 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

tarafından yürütülen işlemlerin sayısı adtech:

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

Kontrol edilecek başka bir şey var mı?


GÜNCELLEME Cmt 21 Tem 09:21:26 ICT 2012:

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

Aşağıdaki yorumda söylediğim gibi, iş arkadaşım belki suçlu olan süreci bulmuştu:

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

Bu süreci öldürerek sorun ortadan kalkar, ancak yine de hangi sınırın aşıldığını bilmiyoruz.


GÜNCELLEME 15 Aralık Cmt 00:56:13 ICT 2012:

@ Favadi 'nin cevabı doğru, ancak birisinin bu konuya girmesi durumunda burada güncelleme yapıyorum.

Günlük dosyası şunları söyledi:

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)

Bu çok açıksa özür dileriz, ancak sisteminizde bir userID 500 var mı? Kullanılacak bir kullanıcı adı ile ilgili mi? İyi şanslar.
shellter

Elbette, adtechkullanıcı UID 500'e sahip. İş arkadaşım, suçlu olan süreci öğrenmişti. Bu işlemi öldürerek sorun ortadan kalkıyor, ancak hala hangi sınırın aşıldığını bilmiyoruz: açık dosyalar yapmıyor, işlem sayısı geçmiyor, belki bellek veya başka bir şey. Düşüncesi olan var mı?
quanta

Bu sürece stra-f -p bağlamayı ve açık bir şekilde başarısız olan sistem çağrılarını ve ne yapmaya çalıştıklarını
aramayı deneyin

Yanıtlar:


12

max user processes (-u) 1024Çok düşük olması mümkün olabilir .

İşlemlerin ve iş parçacıklarının birlikte sayıldığını unutmayın. ps -eLF | grep adtech | wc -lMevcut değerinizi göstermek için kullanabilirsiniz .


7
Daha doğrusu, öyle olmalı ps -eLF -U adtech | wc -l.
12'de quanta

2
Bunun nerede ayarlandığını merak ediyorsanız, /etc/security/limits.d/90-nproc.conf adresine bakın (bir RH sisteminde olduğunuzu varsayarak).
mricon

kontrol @mricon /etc/security/limits.d/90-nproc.confdöner /etc/security/limits.d/90-nproc.conf: No such file or directoryCentOS7 üzerinde
030

@Utrecht iyi, /etc/security/limits.d/ içinde bir "ls" yapmış olabilirsiniz ve EL-7'de "20-nproc.conf" olarak adlandırıldığını fark etmişsinizdir ki bu muhtemelen burada sormaktan daha hızlı olurdu.
mricon

2
@quanta, daha kesin olmak gerekirse, olmalı ps -LF -U adtech | wc -l. -eSeçeneği kullanırken diğer kullanıcıların işlemlerini de alırsınız.
Lambert

2

Kaynak sınırlarına çarptığına dair kanıt için jvm günlüğüne bakın. Öldürülen işlemin kaç tane java iş parçacığı çalıştığına bağlı olarak yığın boyutu sorun olabilir.

Hata mesajınızı aramak pam_keyinit için hata raporları bulur: satıcınızın deposuna güncellenmiş bir sürümün olup olmadığını kontrol edin.


+1. Dersi unuttum: problemi alırken günlüğe bir göz atın. Sorum güncellendi.
12'de quanta

0

Hata tarafından bildirildi pam_keyinit. Bu modüle aşina olmadığım için dokümanları araştırdım ve bu kılavuzu buldum . Açıklamaya dayanarak, belki de öldürdüğünüz işlemin pam_keyinit'in değiştirmesi gereken bazı dosyalara gerekli erişimi engellediğini merak ediyorum? Umarım bu size bir yön verir.


0

Kullanıcının işlem-çalıştırma sınırına ulaşılırsa, bu sorun oluşabilir. İşlem sınırı düzenleyerek artırılabilir: /etc/security/limits.confroot iznine sahip bir kullanıcının bulunduğu dosya. Kontrol edilecek giriş şuna benzer:

*          hard     nproc         100

Herhangi bir hizmeti yeniden başlatmanıza gerek yoktur.


1
Benim durumumda, sert limiti yükseltmenin hemen bir etkisi yoktu; Yumuşak olanı değiştirmek zorunda kaldım.
Nicola Musatti
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.