在前面的文章有介紹過su命令，su命令用于普通用戶和超級(jí)用戶的切換，但在有些系統(tǒng)中，使用su命令無反應(yīng)，那么遇到這種情況該如何處理呢?下面隨學(xué)習(xí)啦小編一起來看看Linux下su命令無反應(yīng)的處理方法。

　　出現(xiàn)問題的系統(tǒng)CentOS 6.3 64位，SSH客戶端使用的是SecureCRT，需要的朋友可以參考下

　　一、問題產(chǎn)生環(huán)境

　　CentOS 6.3 X64

　　SecureCRT 7.0.0 英文版

　　二、問題具體描述

　　今天操作自己的一臺(tái)Linux服務(wù)器時(shí)，突然su命令不好使了，敲入命令回車后，沒有任何反應(yīng)，不管是su還是su -都一樣，重啟系統(tǒng)后也是問題依舊，郁悶的要命。。。

　　最耐心的一次等了大概1分多鐘，出現(xiàn)su：后面的字符是亂碼的提示，當(dāng)時(shí)沒截圖，現(xiàn)在也不想還原問題了，下面說說問題的產(chǎn)生原因和解決方法

　　三、問題產(chǎn)生原因

　　郁悶了半天，才想起來上一次退出登錄前的動(dòng)作是修改了SecureCRT中的字符編碼設(shè)置，設(shè)置路徑：

　　代碼如下：

　　Options 》 Session Options 》 Terminal 》 Appearance 》 Character encoding 》 從default設(shè)為UTF-8

　　如下圖所示：

　　修改成UTF-8的原因是在系統(tǒng)中使用vi編輯帶中文的配置文件時(shí)，出現(xiàn)亂碼的情況，所以根據(jù)以前的經(jīng)驗(yàn)就設(shè)置了SecureCRT中的字符編碼為UTF-8，這樣就不會(huì)亂碼了。

　　問題是記得重裝系統(tǒng)前這樣設(shè)置是沒有任何問題的，也就是不會(huì)導(dǎo)致su命令出現(xiàn)沒有反應(yīng)的情況，非常非常奇怪，再仔細(xì)想了一下，貌似前些日子修改了CentOS的i18n配置，當(dāng)前的i18n配置情況

　　代碼如下：

　　#LANG=“en_US.UTF-8”

　　#SYSFONT=“latarcyrheb-sun16”

　　LANG=“zh_CN.GB18030”

　　LANGUAGE=“zh_CN.GB18030:zh_CN.GB2312:zh_CN”

　　SUPPORTED=“zh_CN.UTF-8:zh_CN:zh:en_US.UTF-8:en_US:en”

　　SYSFONT=“lat0-sun16”

　　記得當(dāng)時(shí)修改這個(gè)配置的原因也是為了解決亂碼問題，結(jié)合當(dāng)前問題，設(shè)想了一下問題的可能原因，然后測(cè)試了一下，果然跟想像的一樣。

　　原因總結(jié)：i18n語言配置為中文并且SecureCRT的Character encoding配置項(xiàng)是UTF-8的情況下，就會(huì)導(dǎo)致su命令沒有任何反應(yīng)。

　　四、問題解決辦法

　　知道了原因，解決起來就簡(jiǎn)單了，我測(cè)試過，把i18n語言項(xiàng)配置成中文，SecureCRT的Character encoding配置成Default的情況下，vi打開包含漢字的配置文件，依然會(huì)亂碼，如果把SecureCRT的Character encoding配置為UTF-8又會(huì)導(dǎo)致su命令不起作用，所以我就把i18n還原成默認(rèn)設(shè)置：

　　代碼如下：

　　LANG=“en_US.UTF-8”

　　SYSFONT=“latarcyrheb-sun16”

　　然后把SecureCRT的Character encoding配置為UTF-8就完美解決了vi打開事漢字的文件亂碼問題，而且又不會(huì)讓su命令出問題，好吧，就這樣吧!!!

　　上面就是Linux下su命令無反應(yīng)的解決方法了，該問題主要出現(xiàn)在CentOS 6.3 64位系統(tǒng)中，如果你不幸中招的話，可以嘗試使用本文的方法進(jìn)行解決。