主页 / server / 问题 / 412114
Accepted
quanta
Asked: 2012-07-20 19:28:25 +0800 CST

无法切换，ssh 到特定用户：su：无法设置用户 ID：资源暂时不可用？

  • 772

/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

我猜这是由每个用户限制引起的，但与另一个用户相比并没有什么不同。

这是ulimit -n为了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

这个是为了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

运行的进程数adtech：

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

还有什么要检查的吗？

更新 7 月 21 日星期六 09:21:26 ICT 2012：

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

正如我在下面的评论中所说，我的同事发现了可能是罪魁祸首的过程：

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

通过终止这个进程，问题就消失了，但我们仍然不知道超出了哪个限制。

更新 12 月 15 日星期六 00:56:13 ICT 2012：

@favadi的回答是正确的，但我在这里更新以防有人谷歌这个线程。

日志文件说：

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)
ulimit

4 个回答

  1. Best Answer

    可能max user processes (-u) 1024是太低了。

    请记住，进程和线程是一起计数的。您可以ps -eLF | grep adtech | wc -l用来显示您的当前值。

    • 12

  2. 在 jvm 日志中查找它达到资源限制的证据。堆栈大小可能是问题所在，具体取决于被杀死的进程正在运行的 Java 线程数。

    搜索您的错误消息可找到 pam_keyinit 的错误报告：检查供应商的存储库是否有可用的更新版本。

    • 2

  3. 错误由 报告pam_keyinit。由于我不熟悉这个模块，所以我搜索了文档并找到了这个联机帮助页。根据描述，我想知道您杀死的进程是否阻止了对 pam_keyinit 需要修改的某些文件的必要访问？希望这能给你一些指导。

    • 0

  4. 如果达到用户的进程运行限制，则可能会发生此问题。可以通过编辑来增加进程限制：/etc/security/limits.conf具有 root 权限的用户的文件。要检查的条目将类似于：

    *          hard     nproc         100

    无需重新启动任何服务。

    • 0

相关问题