/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
Je suppose que cela est dû à la limite par utilisateur, mais il n'y a pas de différence lors de la comparaison avec un autre utilisateur.
Voici ulimit -n
pour 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
et celui-ci pour 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
le nombre de processus exécutés par adtech
:
[root@hmaster87 ~]# ps -U adtech | wc -l
25
Autre chose à vérifier?
MISE À JOUR sam 21 juil 09:21:26 ICT 2012:
# getent passwd adtech
adtech:x:500:502::/home/adtech:/bin/bash
Comme je l'ai dit dans le commentaire ci-dessous, mon collègue avait découvert le processus qui était peut-être le coupable:
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
En tuant ce processus, le problème disparaît, mais nous ne savons toujours pas quelle limite a été dépassée.
MISE À JOUR sam 15 déc 00:56:13 ICT 2012:
La réponse de @ favadi est juste, mais je mets à jour ici au cas où quelqu'un google ce fil.
Le fichier journal indiquait que:
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)
Il est possible que la max user processes (-u) 1024
soit trop basse.
N'oubliez pas que les processus et les threads comptent ensemble. Vous pouvez utiliser ps -eLF | grep adtech | wc -l
pour afficher votre valeur actuelle.
Recherchez dans le journal jvm la preuve qu'il atteint des limites de ressources. La taille de la pile peut être le problème, selon le nombre de threads Java exécutés par le processus tué).
La recherche sur votre message d'erreur trouve des rapports de bogues pour pam_keyinit: vérifiez auprès du référentiel de votre fournisseur si une version mise à jour est disponible.
Ce problème peut se produire si la limite d'exécution de processus de l'utilisateur est atteinte. La limite de processus peut être augmentée en modifiant: /etc/security/limits.conf
fichier avec un utilisateur disposant des droits root. L'entrée à vérifier sera similaire à:
* hard nproc 100
Pas besoin de redémarrer les services.
L'erreur a été signalée par pam_keyinit
. Comme je ne connais pas ce module, j'ai cherché de la documentation et j'ai trouvé ceci page de manuel . Sur la base de la description, je me demande si le processus que vous avez tué a peut-être empêché l'accès nécessaire à certains fichiers que pam_keyinit doit modifier? J'espère que cela vous donne une certaine direction.