Estaba trasteando un poco con una nueva partición e instalación de tw, que me hice en el equipo, aunque no le veo mayor incidencia, empecé usando wayland y después de un par de días usándolo, me pasé otra vez al x11, ya que tuve algún fallo de arranque y solo me iniciaba en consola; para arrancarlo tenía que loguearme con mi usuario y startx, cosa que no me ocurre con x11 (solo lo comento a titulo de curiosidad), estaba usando xdm.service y noté un error en los logs, busque en la red y vi que recomendaban usar más sddm, así que por probar lo desactivé y activé el sddm:
systemctl disable xdm.service && systemctl enable sddm.service sin mayores consecuencias, pero cuando he pedido el status veo un error que puede ser insignificate, pero que no llego a comprender, ya que todo funciona correctamente.
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: pam_unix(sddm-autologin:session): session opened for user soyasi2(uid=1000) by soyasi2(uid=0)
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: pam_sm_open_session
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: open_session called without kwallet5_key
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: [PAM] Preparing to converse…
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: [PAM] Conversation with 1 messages
ene 30 00:33:22 soyasi2.site sddm[5651]: Authentication information: SDDM::Auth::INFO_UNKNOWN “Last login: mar ene 30 00:25:32 WET 2024 from :0 on tty2”
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: Writing cookie to “/tmp/xauth_OUHtnr”
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: Starting X11 session: “” “/usr/etc/X11/xdm/Xsession "/usr/bin/startplasma-x11"”
ene 30 00:33:22 soyasi2.site sddm[5651]: Session started true
ene 30 00:33:22 soyasi2.site sddm-helper[5676]: Failed to write utmpx: No existe el fichero o el directorio
Pero el fallo se dá en ambos casos Failed to write utmpx:
Yo tengo justo ese problema, pero también tengo una regresión que hace que algún proceso se quede colgado y no sea capaz de cerrarlo (así que el sistema se tira un minuto y medio intentando cerrarlo al apagar o reiniciar!).
Por otra parte, no lo has hecho del todo bien . xdm service arranca el gestor de sesiones que tengas configurado para ello: si es sddm, arranca sddm, si es otro, arrancará otro. De hecho yo el error lo saco con status xdm
Tengo alguna máquina virtual que no me arroja ese error pero find no me da diferencias sustanciales como para explicarlo. Ah, sí, se supone que eso tiene que ver con el registro de sesiones etc, y por lo visto es un warning, no un error.
Tengo otra máquina virtual y aunque me da el mismo warning al menos se me apaga correctamente. Y otra con Plasma 6 en lugar de ese warning me da otro: Authentication information: SDDM::Auth::INFO_UNKNOWN “Last login: Xov Xan 11 18:48:57 CET 2024 from :0 on tty2”
Por supuesto, mis “problemillas” de apagado suenan más a algún problema con los drivers nvidia que con otra cosa.
Pues básicamente, tengo la normal de trabajo con xdm y la nueva con sddm, generé la nueva porque tengo el mismo problema de apagado que tú, tarda 1:30 minutos en apagarse y no encuentro el error, salvo que en ambos conincide el Failed to write utmpx: pero viendo el man de utmp dudo que sea el problema. Tanto en xdm como en sddm me da el mismo warning que reportas: Authentication information: SDDM::Auth::INFO_UNKNOWN “Last login: mar ene 30 00:25:32 WET 2024 from :0 on tty2. Seguiré buscando información, pero de momento no encuentro nada parecido, así que seguiré probando “cosas” en la partición nueva. No creo que sea los drivers de nvidia, ya que uso los amdgpu y me pasa lo mismo.
sudo systemctl status xdm no ofrece warnings. Apaga normalmente.
Arranco el sistema. sudo systemctl status xdm me ofrece el warning failed to write utmpx. Tengo que reiniciar a ver qué hace.
Apaga normalmente.
sudo systemctl status xdm sigue ofreciendo ese warning pero ningún otro.
(Tengo que fijarme en el de escritorio si tengo los dos warnings)
En el escritorio tengo el warning failed to write utmpx y al apagar tiene el proceso ése esperando 1:30 minutos.
Hace tiempo tuve un problema similar o igual (con el mismo resultado de tardar en apagarse mientras esperaba el minuto y medio de marras) pero se solucionó en una actualización. Hace unas semanas me volvió a pasar en los dos equipos, pero en el portátil volvió a solucionarse, no así en el de escritorio. Mis MV no sirven de prueba principalmente porque tendría que actualizarlas y a saber
Tengo configurado que guarde la sesión. Voy a probar a no guardar nada. Si tardo más de un par de minutos es que no sirvió de nada
Como era de esperar, no sirvió. El único fallo que veo en la consola F10 es akonadi, pero eso no debería ser.
y el status de mi xdm, no se diferencia mucho del sddm
localhost:/home/soyasi # systemctl status xdm.service
● display-manager.service - X Display Manager
Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; preset: enabled)
Active: active (running) since Tue 2024-01-30 16:58:39 WET; 45s ago
Process: 2086 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
Main PID: 2100 (sddm)
Tasks: 13 (limit: 4915)
CPU: 1.911s
CGroup: /system.slice/display-manager.service
├─2100 /usr/bin/sddm
└─2102 /usr/bin/Xorg.bin -dpi 192 -background none -seat seat0 vt2 -auth /run/sddm/xauth_egtkNC -noreset -displayfd 16
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: pam_unix(sddm-autologin:session): session opened for user soyasi(uid=1000) by soyasi(uid=0)
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: pam_sm_open_session
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: pam_kwallet5(sddm-autologin:session): pam_kwallet5: open_session called without kwallet5_key
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: [PAM] Preparing to converse...
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: [PAM] Conversation with 1 messages
ene 30 16:58:40 localhost.localdomain sddm[2100]: **Authentication information: SDDM::Auth::INFO_UNKNOWN "Last login: mar ene 30 16:52:16 WET 2024 from :0 on tty2**
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: Writing cookie to "/tmp/xauth_lxTjjP"
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: Starting X11 session: "" "/usr/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\""
ene 30 16:58:40 localhost.localdomain sddm[2100]: Session started true
ene 30 16:58:40 localhost.localdomain sddm-helper[2344]: **Failed to write utmpx:** No existe el fichero o el directorio
@soyasi el error es el mismo que el mío, xdm.service y sddm.service no se diferencian porque xdm no carga xdm como hacía antes, sino que carga el gestor de sesiones que tengas, que en este caso es sddm.
He estado trasteando con paridas para monitorizar el arranque, he instalado tuptime con un script desde github y al deshabilitarlo por lo que sea ahora apaga bien
el warning de Authentication information: SDDM::Auth::INFO_UNKNOWN "Last login: mar ene 30 16:52:16 WET 2024 from :0 on tty2 se elimina quitando el login automático, así que esto tampoco es.
ene 30 18:01:20 soyasi2.site sddm[1901]: Authentication for user “soyasi2” successful
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
ene 30 18:01:20 soyasi2.site sddm[1901]: Auth: sddm-helper exited successfully
ene 30 18:01:20 soyasi2.site sddm[1901]: Greeter stopped. SDDM::Auth::HELPER_SUCCESS
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: pam_unix(sddm:session): session opened for user soyasi2(uid=1000) by soyasi2(uid=0)
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: Writing cookie to “/tmp/xauth_ignbGJ”
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: Starting X11 session: “” “/usr/etc/X11/xdm/Xsession "/usr/bin/startplasma-x11"”
ene 30 18:01:20 soyasi2.site sddm[1901]: Session started true
ene 30 18:01:20 soyasi2.site sddm-helper[2005]: Failed to write utmpx: No existe el fichero o el directorio
solo me falta saber el que comenté al principio Failed to write utmpx: No existe el fichero o el directorio, aunque debe de ser otra cosa …
Es una buena pregunta. Yo entiendo que no afecta y que ni siquiera va por aquí, porque ahora mismo tanto el de escritorio como el portátil apagan correctametne (aunque puede que sea gafe y cuando cierre aquí ya no apague bien
tux@escritorio:~> sudo systemctl status xdm
[sudo] password for root:
● display-manager.service - X Display Manager
Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; preset: enabled)
Active: active (running) since Tue 2024-01-30 18:45:08 CET; 26min ago
Process: 1751 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
Main PID: 1763 (sddm)
Tasks: 4 (limit: 4915)
CPU: 17.356s
CGroup: /system.slice/display-manager.service
├─1763 /usr/bin/sddm
└─1780 /usr/bin/Xorg.bin -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_IParZR -noreset -displayfd 16
Xan 30 18:45:17 escritorio sddm[1763]: Authentication for user "tux" successful
Xan 30 18:45:17 escritorio sddm-helper[1904]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
Xan 30 18:45:17 escritorio sddm[1763]: Auth: sddm-helper exited successfully
Xan 30 18:45:17 escritorio sddm[1763]: Greeter stopped. SDDM::Auth::HELPER_SUCCESS
Xan 30 18:45:17 escritorio sddm-helper[1904]: pam_unix(sddm:session): session opened for user tux(uid=1000) by tux(uid=0)
Xan 30 18:45:17 escritorio sddm-helper[1904]: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
Xan 30 18:45:17 escritorio sddm-helper[1904]: Writing cookie to "/tmp/xauth_CwGIeg"
Xan 30 18:45:17 escritorio sddm-helper[1904]: Starting X11 session: "" "/usr/etc/X11/xdm/Xsession \"/usr/bin/startplasma-x11\""
Xan 30 18:45:17 escritorio sddm[1763]: Session started true
Xan 30 18:45:17 escritorio sddm-helper[1904]: Failed to write utmpx: Non hai tal ficheiro ou directorio
Supuestamente es algo que queda colgado de la sesión de escritorio, o algo que está marcado como en funcionamiento pero que no lo está y entonces no lo puede apagar. Algo así raro y trivial.
Solucioné lo de que se apagara más rápido, solo hay que hacer en consola un
cp /usr/lib/systemd/system.conf /etc/systemd/system.conf.d/system.conf, después editar el archivo, quitar los # de las lineas y bajar los tiempos, se me ha quedado de esta forma
DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s
Pero sigo sin solucionar lo del Failed to write utmpx: No existe el fichero o el directorio
Aunque la vez anterior ya había visto propuestas de solución que pasaban por acortar el tiempo en el que se espera a que el proceso se cierre, había preferido esperar a que se solucionase, porque sea lo que sea que evita que el sistema se cierre sigue ahí: simplemente, sean 90 o 5 segundos, al acabar el tiempo de espera se continúa el apagado.
No creo que haya relación entre el gestor de sesiones y esto. Puedes probar a iniciar el sistema hasta que el gestor de sesiones te pida usuario/clave y apagar desde ahí a ver qué pasa. Yo creo recordar que en ese caso se cerraba bien (pero no si la sesión se iniciaba con un usuario, se salía de ella de nuevo al gestor de sesiones y se apagaba desde ahí). Si pensé que podía haber relación, es que como en tu caso es un fallo que aparece “de la nada” y que, igual que el de cerrar la sesión, no debería suceder. Así que mi conjetura era algo así como que el proceso “colgado” era alguna comprobación o anotación relativa a la sesión de usuario, tal que podía ser que al no encontrar el fichero se quedase ahí sin poder continuar…
Este error lo tuve hace tiempo, desapareció con las actualizaciones, volvió a aparecerme hace unas semanas y volvió a irse como vino (salvo la coincidencia de que en el de escritorio había hecho una pequeña actualización un par de reinicios antes, pero no antes de la sesión que sí pude apagar correctamente, y lo único que estaba haciendo era buscar registros de alguna clase para ver qué podía ser, e instalé tuptime y lo deshabilité con la misma porque no ofrece más que registros temporales, nada de qué está pasando)
Tienes razón, si no entro en la sesión grafica y reinicio no hay problema de ningún tipo.
He utilizado journalctl --boot=-1 --priority=4 --no-pager
por si encontraba algo que me diera una pista y he visto este salto de tiempo:
ene 31 17:46:35 soyasi2.site systemd[1]: Stopped Session 3 of User soyasi2.
ene 31 17:46:35 soyasi2.site systemd[1]: session-3.scope: Failed with result ‘timeout’.
ene 31 17:46:35 soyasi2.site systemd[1]: session-3.scope: Killing process 3865 (libusb_event) with signal SIGKILL.
ene 31 17:46:35 soyasi2.site systemd[1]: session-3.scope: Killing process 3862 (scdaemon) with signal SIGKILL.
ene 31 17:46:35 soyasi2.site systemd[1]: session-3.scope: Stopping timed out. Killing.
ene 31 17:45:07 soyasi2.site NetworkManager[1491]: [1706723107.2335] device (p2p-dev-wlp5s0): supplicant management interface state: completed → disconnected
es el único proceso que coincide segundo arriba/abajo con el tiempo de los 90 segundos de las 2567 lineas que me ha dado, pero que ahora mismo, ni idea de lo que es.
Hola:
Es normal, tener 2 gestores de pantalla, en un sistema xdm, del x y sddm de plasma (sucesor de kdm) ? .
Es normal que systemd, dedique un tiempo y un nº de intentos en reponer un servicio, si no lo consigue, continua con la ejecución ( antiguamente podía quedarse bloqueado en ese sitio) .
Ejemplo tener un nas, systemd intentara montar el dispositivo, pero si está apagado, después de un nº de intentos, continua la ejecución del sistema ( de 3 a 5 intentos, aparce un * en rojo, desplazando se de izq a derecha) .
Según eso sería o bien libusb_event o bien scdaemon. Tienes algún lector de tarjetas enchufado? Prueba a desenchufarlo antes de apagar. Claro que tendrías que ponerle más timeout para ver si funciona
No, pero ahora xdm maneja el servidor que tengas configurado (que puede ser xdm, sddm, gdm, kdm…).
Como ves, el proceso es display-manager, y eso lo que hace es poner en marcha el gestor definido en /etc/sysconfig/displaymanager (lo cual puedes hacer con el editor de sysconfig de YaST).
Sí, pero en este caso es un bug de alguna clase. De hecho, precisamente lo que sucede es que al cerrar la sesión hay algo que se queda “colgado” o no avisa de que está bien cerrado o lo que sea, y por tanto systemd espera el límite definido como timeout (90 segundos por defecto). Lo cual es bastante molesto, en mi caso porque quiero apagar la regleta al apagar la PC.
. xdm service arranca el gestor de sesiones que tengas configurado para ello: si es sddm, arranca sddm, si es otro, arrancará otro. De hecho yo el error lo saco con status xdm 
