/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)
adtech
utilisateur a l'UID 500. Voir ma mise à jour. Mon collègue avait découvert le processus qui est coupable. En tuant ce processus, le problème disparaît, mais nous ne savons toujours pas quelle limite a été dépassée: les fichiers ouverts ne le font pas, le nombre de processus ne le fait pas, peut-être la mémoire ou autre chose. Des pensées?Réponses:
Il est possible que la valeur
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.la source
ps -eLF -U adtech | wc -l
./etc/security/limits.d/90-nproc.conf
retours/etc/security/limits.d/90-nproc.conf: No such file or directory
sur CentOS7ps -LF -U adtech | wc -l
. Lorsque vous utilisez l'-e
option, vous obtenez également d'autres processus utilisateurs.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.
la source
L'erreur a été signalée par
pam_keyinit
. Comme je ne connais pas ce module, j'ai recherché de la documentation et trouvé cette 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.la source
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 éditant:
/etc/security/limits.conf
fichier avec un utilisateur ayant l'autorisation root. L'entrée à vérifier sera similaire à:Pas besoin de redémarrer les services.
la source