Cómo lidiar con la falta de suministro del comando su en Linux

En el artículo anterior, se introdujo el comando su. El comando su se usa para el cambio de usuario normal y superusuario. Sin embargo, en algunos sistemas, el comando su se usa sin respuesta. ¿Cómo lidiar con esta situación? Echemos un vistazo al método de procesamiento no resuelto del comando su en Linux.

El sistema problemático CentOS 6.3 de 64 bits, el cliente SSH usa SecureCRT, necesita que los amigos puedan consultar el siguiente

Primero, el entorno que produce problemas

CentOS 6.3 X64 < Br>

SecureCRT 7.0.0 Inglés

En segundo lugar, la descripción del problema

Cuando opero mi propio servidor Linux hoy, de repente el comando su no es bueno, vuelva a escribir el comando Después del automóvil, no hay reacción, ya sea su o su - lo mismo, después de reiniciar el sistema sigue siendo el problema, deprimido y terrible. . .

El paciente más paciente esperó durante aproximadamente 1 minuto, y el su: el personaje que estaba detrás era un indicador confuso. En ese momento no había una captura de pantalla. Ahora no quiero restaurar el problema. Permítame hablar sobre la causa y la solución del problema.

En tercer lugar, la causa del problema

Durante mucho tiempo, se deprime, solo para recordar la última acción antes de cerrar sesión es modificar la configuración de codificación de caracteres en SecureCRT, establecer la ruta:

código es el siguiente:

Opciones de "Opciones de sesión" Terminal "Aspecto" codificación de caracteres "se establece en el valor por defecto UTF-8

como se muestra a continuación:

modificado que El motivo de UTF-8 es que cuando se usa vi para editar el archivo de configuración con chino en el sistema, aparecen caracteres confusos, por lo que, según la experiencia anterior, la codificación de caracteres en SecureCRT se establece en UTF-8, para que no se confunda.

El problema es que no hay ningún problema en la configuración de este sistema antes de volver a instalarlo, es decir, no hará que el comando su parezca que no responde. Es muy extraño. Lo pienso de nuevo. Parece que se modificó hace unos días. Configuración de CentOS i18n, configuración actual de i18n

El código es el siguiente:

# LANG = " en_US.UTF-8 "

# SYSFONT = " latarcyrheb-sun16 "

LANG = " zh_CN.GB18030 "

LANGUAGE = " zh_CN.GB18030: zh_CN.GB2312: zh_CN "

SUPPORTED = " zh_CN.UT : zh_CN: zh: en_US.UTF-8: en_US: en "

SYSFONT = " lat0-sun16 "

Recuerdo que la razón para modificar esta configuración en el momento también fue para resolver el problema confuso, combinado con el actual Pregunta, imagina las posibles razones del problema y luego examínalo, y es como se esperaba.

Resumen de motivos: si la configuración de idioma de i18n es chino y el elemento de configuración de codificación de caracteres SecureCRT es UTF-8, el comando su no tendrá respuesta.

En cuarto lugar, la solución del problema

Conozca la razón, la solución es simple, probé, el elemento de idioma i18n está configurado en chino, la codificación de caracteres de SecureCRT está configurada como predeterminada, Vi abrir el archivo de configuración que contiene caracteres chinos, aún confuso, si la configuración de la codificación de caracteres SecureCRT en UTF-8 hará que el comando su no funcione, por lo que restauraré i18n a la configuración predeterminada: el código

es el siguiente :

LANG = " en_US.UTF-8 "

SYSFONT = " latarcyrheb-sun16 "

Luego configure la codificación de caracteres de SecureCRT en UTF-8. Resolvió el problema de los archivos confusos en los caracteres chinos abiertos, y no dejará que los problemas de comando su, bueno, ¡así de simple! ! !

Lo anterior es la solución no resuelta para el comando su en Linux. Este problema se produce principalmente en el sistema de 64 bits de CentOS 6.3. Si tiene la mala suerte, puede intentar resolverlo utilizando el método de este artículo.