背景：
開發反映使用普通賬號無法登錄服務器；
我使用root賬號可以登錄，但在切換普通用戶以及在終端SSH登錄的時候報如下錯誤
[root@localhost ~]# su - dy
su: cannot set user id: Resource temporarily unavailable
ssh [email protected] 報 "Write failed: Broken pipe"問題
分析：
這是什麼問題呢？說實話好長時間沒遇到這種問題了，不知道是什麼原因引起的，立及百度。後來發現跟文件句柄數有關係，同事也說調大文件數就OK了。參考鏈接：http://www.361way.com/resource-ulimit/2611.html
我查看文件句柄數，詳細如下：
[root@localhost ~]# 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) 63710
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 102400
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) 102400
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
沒有問題啊，文件句柄數高達102400個呢。
查看/etc/security/limits.conf文件，詳細如下
* soft nofile 102400
* hard nofile 102400
* soft nproc 102400
* hard nproc 102400
沒有問題啊，文件句柄數同樣是102400個，也很大啊。文件句柄數很大啊，怎麼普通用戶還不能登錄，是不是在哪裏有限制啊。
解決方案：
修改下面的文件，把1024調整爲102400
[root@localhost ~]# cat /etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
* soft nproc 1024
root soft nproc unlimited
總結
爲什麼會遇到這種非常鎖碎的問題呢？說實話我真的好長時間沒遇到這種問題了，而且覺得這種問題也不應該出現。我目前剛來新公司，發現公司在運維方面還沒形成體系，每購買或創建一臺服務器，都沒有先做系統性的優化。所以，今天這臺調大了，但別的服務器沒有調，那麼一旦出現問題還得調，這樣就耽誤了運維的時間並增加了運維的工作量。像上面的文件句柄數是102400，這個我們運維並沒有做優化，應該是雲服務商自己做的優化，但優化的還不是很到位。所以，公司有一套自己的系統優化方案是很有必要的。