Cuando abro la Terminal, me sale un "¡No tengo nombre!" oportuno

De repente, esta mañana, abro una ventana de Terminal y me sale esto:

I have no name!@macbook:~$ whoami
502

** ¡No soy un número! ¡Soy un ser humano! **

¿Lo que da? Alguien sabe que debo hacer para recuperar mi nombre?

Supongo que hay dos problemas aquí, uno es que mi nombre de host no está definido, el otro es que whoami reporta mi nombre como un número.

Por cierto, para aquellos interesados, me desconecté (command-shift-Q) y después de volver a iniciar sesión y reiniciar la terminal, ¡el problema desapareció! Todavía estoy interesado en lo que pudo haber causado esto, aunque solo sea para mejorar el estado de mi McKnowledge.
¿Está preguntando por qué el nombre de host de la computadora se muestra en el aviso o está preguntando por qué la computadora se llama “¡No tengo nombre!”?
Estoy preguntando por qué, de repente, mi aviso de bash muestra "¡No tengo nombre!" en lugar de un nombre de host. Tal vez sea solo una coincidencia que whoamitambién informe mi número en lugar de mi nombre.
¿Qué hacer hostnamey id -pvolver?
mi sistema ha vuelto a la normalidad. Sin embargo, es una buena sugerencia, si vuelve a suceder, ¡los revisaré a ambos!
Esto me sucedió dos veces en las últimas dos semanas. Anoche ejecuté Verify Disk desde Disk Utility y encontró errores. He hecho el disco de reparación de sus instrucciones. Es posible que desee probar eso también. Puede ser que nuestros discos se estén estropeando.
Me pasa después de despertar - 10.7.3 y 10.7.4. Casi 13" MBP 2010, 8G ram y SSD Intel. Solo reiniciar soluciona este problema. Parece un problema de software.
Lo mismo le pasó a mi Macbook air 2008, 8Gb, OSX 10.7.5. No bloqueé los programas a la fuerza: solo a veces Libreoffice no respondía. Reiniciar ayuda.
Vi este error al intentar enviar una rama a Github. Me tomó un tiempo descubrir la causa raíz: solo lo obtuve cuando traté de verificar si mi clave pública coincidía con lo que estaba almacenado en GH.

Respuestas (10)

Algo en la memoria se corrompió y se perdió la asignación entre su ID de usuario (502) y su nombre de usuario (ipd). Lo he visto suceder (generalmente cuando eliminé manualmente los procesos del sistema colgados), aunque no estoy seguro exactamente de qué lo causa. launchd¿quizás?

Debido a que esa asignación se perdió, whoamino puede convertir su ID en un nombre de usuario, por lo que devuelve la ID y su mensaje predeterminado es "¡No tengo nombre!" mensaje porque efectivamente no tienes un nombre.

Cerrar sesión y volver a iniciarla podría solucionarlo, pero reiniciar es la mejor manera (como descubrió).

Básicamente, es un síntoma de otro problema y no un problema en sí mismo.

Desearía poder explicar cómo se pierde ese mapeo, pero nunca profundicé lo suficiente como para resolverlo.
Esto me acaba de pasar de nuevo. Lo había matado launchd, y lo estaba ahora 501, lo que me impedía consumir sudo. Todavía no sé si launchdse reiniciará solo o qué más afectará si no se ejecuta.
Por lo que vale, me encontré con esto en una máquina Linux, así que supongo que la causa raíz es algo en bash.strings /bin/bash | grep "I have"
Esto también pasa en los sandboxes, donde es común no tener whoami o incluso sus dependencias, prueba which whoamia ver donde está, en mi caso lo hice ldd /usr/bin/whoamipara buscar dependencias, ver si las tienes y/o si están dañadas.

Veo que es un hilo antiguo, pero aquí está la solución a este problema (sin reiniciar toda la computadora).

El problema está en el opendirectoryddaemon y los primeros informes datan de principios de 2011. Reiniciar el daemon (cambiar de usuario con uno de administrador a través de Fast User Switching) soluciona el problema.

Mientras escribía esta respuesta, encontré una pregunta similar en Serverfault here , que también cubre mi respuesta.

Esto no funcionó para mí. Mis síntomas son quizás un poquito diferentes. Tengo varias ventanas de terminal abiertas, y cada ventana de terminal existente ha perdido su asignación de nombre de usuario, pero cada ventana nueva parece tenerlo sin problemas. Matar (también conocido como reiniciar) opendirectoryd no ayudó. En los terminales "fallidos", también me falta el mapeo de grupos para com.apple.sharepoint.group.2y access_bpf, pero no los grupos enumerados en /etc/group. Me parece que los viejos procesos de terminal (y quién sabe qué más) han perdido el acceso a opendirectoryd, no que opendirectoryd haya fallado.

Esto me sucede aleatoriamente cuando salgo del modo de espera (es decir, cuando abro mi computadora portátil). Cerrar sesión o reiniciar es la única forma de solucionarlo. No sé exactamente qué lo causa. Mientras escribo, está sucediendo ahora mismo. Como preguntaba el comentario en la publicación original, corrí id -py se bloqueó. (Informe de falla: http://pastebin.com/nmFFQELq )

Comandos de consola:

whoami— devuelve 501

id -p— accidentes

cat /etc/passwd— mi usuario no está en el documento.

Cualquier intento de ssh falla con el error:

¡Tú no existes, vete!

También revisé la consola, al despertar, aparecen un montón de errores aleatorios de "Socket no conectado" (lo que creo que podría ser normal, ya que la conexión inalámbrica no se conecta de inmediato) de programas como Dropbox. Sin embargo, aparece un error interesante:

12/4/12 8:37:09.045 PM coreservicesd: _scserver_ServerCheckin: error de validación del uid del cliente; getpwuid(501) == NULO

12/4/12 8:37:09.400 PM coreservicesd: _scserver_ServerCheckin: error de validación de uid del cliente; getpwuid(501) == NULO

Todavía no estoy seguro de qué lo está causando, pero pensé en compartir estos diagnósticos.

Tengo un MacBook Pro de mediados de 2009 con 10.7.3 instalado.

Vea si los permisos del archivo /etc/passwdestán configurados así:

-rwxr--r--

porque lee el nombre de usuario del passwdarchivo.

Era 644, no 744. Establecer en 744 no ayudó.

Tuve este mismo problema desconcertante hoy (Lion 10.7.5) y dscacheutil -flushcachelo solucioné, como se sugiere en un comentario en algún blog .

Resolví el problema usando iterm=>preferences=>URL_handler y conectando whoami a mi nombre de usuario... después de reiniciar en iterm, el problema ya no existía

Asegúrese de que los permisos de su archivo /etc/passwd sean 644

chmod 644 /etc/passwd

Después de cambiar los permisos, cierre sesión y vuelva a iniciar sesión

Es interesante que otras respuestas digan que los permisos 644/744 no son relevantes o completos para resolver esto. ¿Existe una referencia sobre cuáles deberían ser los permisos adecuados y cuándo desviarse de ellos?

Mi problema es el permiso en el archivo passwd. El permiso anterior es -rw------- 1 root root 1280 9 de junio 15:41 passwd Usé el comando "chmod a+r /etc/passwd" y ahora todos los usuarios puede leer este archivo. -rw-r--r-- 1 raíz raíz 1280 9 de junio 15:41 contraseña Cierre la sesión del usuario e intente. =)

Tuve este extraño problema en mi ubuntu cuando creé un nuevo usuario

Revisé el archivo /etc/passwd

`cat /etc/passwd`

Vi que mi registro tenía los siguientes detalles:

`ajit:x:1002:1002::/home/ajitp:/bin/sh`

Lo cambié de la siguiente manera:

`ajit:x:1002:1002::/home/ajitp:/bin/bash`
Esto no proporciona una respuesta a la pregunta. Una vez que tenga suficiente reputación , podrá comentar cualquier publicación ; en su lugar, proporcione respuestas que no requieran aclaración por parte del autor de la pregunta . - De la revisión

Vaya a la carpeta de inicio en Terminal y ejecute . ~/.bashrc.

¡¡Funciona!!

No creo que re-sourcing .bashrc resuelva el problema aquí...