El siguiente mensaje aparece casi cada vez que apago mi computadora:
A stop job is running for Session c2 of user ... (1min 30s)
Espera 1 minuto y 30 segundos y luego continúa el proceso de apagado. Sigo esta guía de diagnóstico de apagado de systemd y obtengo shutdown-log.txt (no puedo pegar directamente el registro aquí porque es muy largo). Desafortunadamente, no entiendo el registro por mí mismo. ¿Alguien podría ayudarme a descubrir qué hace que mi sistema no se apague correctamente?
Ejecuto Arch Linux con kernel 4.4.5-1-ARCH
, mi systemd
versión es 229-3
.
Adición 1: Observo que cada vez que cierro la sesión y luego apago mi computadora desde la pantalla de inicio de sesión, no aparece el mensaje A stop job is running...
. Intenté cerrar sesión antes del apagado muchas veces, así que creo que no ocurre por casualidad. Espero que la información pueda ayudar.
Adición 2: siempre es la sesión c2 la que causa el apagado. Entonces, como sugiere @ n.st, volví a mirar Diagnóstico de problemas de apagado y lo almacené en loginctl session-status c2
lugar de dmesg
, pero luego no hay nada en el shutdown-log.txt
. He sustituido loginctl session-status c2
por systemd-cgls
y obtuve el siguiente registro:
Control group /:
-.slice
└─init.scope
├─ 1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
└─1074 systemd-cgls
¿Algunas ideas?
Nota: Después de actualizar a kernel 4.6.4-1-ARCH
y systemd 230-7
, el error ya no ocurrió.
dmesg
salida que pegó no es muy informativa: muestra la desconexión de WiFi cuando presiona el botón de apagado (3048 segundos después del arranque del sistema) y luego nada hasta que expira el temporizador de 1m30s y el sistema continúa apagándose (a 3139 segundos).loginctl session-status c2
. No estoy seguro de si aún puede cambiar a un getty durante el apagado, pero intente presionar Ctrl + Alt + F2 cuando aparezca "Se está ejecutando un trabajo de detención ...". Si eso funciona, recibirá un mensaje de inicio de sesión y podrá usar elloginctl
comando. Si no recibe un mensaje de inicio de sesión, siga los mismos pasos que usódmesg
, pero almacene el resultado deloginctl session-status c2
. (Todo eso supone que siempre es "c2" lo que cuelga, no otra sesión cada vez)./etc/sysctl.d/50-coredump.conf
con contenido:,kernel.core_pattern=core
ref: github.com/systemd/systemd/issues/1615#issuecomment-203507283loginctl session-status c2
lugar dedmesg
.Respuestas:
Una solución a este problema es reducir este tiempo de espera
/etc/systemd/system.conf
de 90 a, por ejemplo, 10 segundos:y ejecuta el siguiente comando en la terminal después de hacer cambios
fuente
Este problema puede tener muchas causas, por lo que las respuestas específicas no funcionan demasiado bien. Pruebe esto para solucionar problemas:
journalctl -p5
en una terminal y presionarEND
para llegar al final del diario systemd (-p5
filtra mucha basura)/
e ingresar el término de búsquedatimed out. Killing.
SHIFT+N
repetidamenteKilling process 1234 (jack_thru) with signal SIGKILL.
Si siempre es la misma aplicación, desea averiguar qué hace y por qué no se detiene en el apagado. De lo contrario, podría ser más complicado resolver el problema, pero aún podría obtener una pista o dos.
¡Buena suerte! :)
fuente
Tuve el mismo problema, buscando encontré una publicación en un foro reddit de Arch Linux.
Aquí está la solución que me funciona https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u
Creo una esencia para este https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3
fuente
watchdog
, el hardware reiniciará el sistema si se atrasa o falla otras pruebas. Entonces, cuando ocurre el tiempo de espera en la pregunta, watchdog reiniciará la computadora. Me pregunto si el sistema se cerraría de manera más limpia si simplemente redujimos el tiempo de espera según la otra respuesta. También me pregunto siwatchdog
forzaría un reinicio en otras situaciones no deseadas.Encontré una solución aquí que me funcionó con Debian 9 en vbox. Estaba recibiendo el retraso típico de 120 segundos al apagar o reiniciar.
https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown
Haz lo que Ironman dice:
Usé "sudo shutdown now" y el retraso de reinicio ya no está. Parece demasiado simple, pero funcionó para mí (y para otros).
HTH
fuente
Habiendo tenido un problema similar en Kali [2017.01], con un retraso de cierre de sesión alternativo mostrado por
Logré eliminar un error deteniéndome primero
NetworkManager
antes de apagarlo o deshabilitarlo, con:Esto probablemente debería repararse o ponerse de otra manera al reiniciar.
En cuanto a la otra demora, no he tenido éxito. Parece que puede estar relacionado con GDM ( Gnome Display Manager ),
pulseaudio
odbus
. Entonces, como no pude aislar el problema, la única forma era establecer lasDefaultTimeout*Sec=5s
entradassystem.conf
como ya se mencionó en otras publicaciones.Otros problemas que pueden investigarse se muestran en:
y:
fuente
poweroff
o noshutdown
podemos iniciar sesión para ver al culpable real. systemd necesita registrar la salida de cgls cuando ocurre este problema. Lo mejor que podemos hacer por ahora es guardar el resultado y consultarlo más tarde si / cuando el bloqueo vuelve a ocurrir.systemd-cgls
Dado que este es uno de los primeros resultados en el motor de búsqueda más amigable, agregaré mi solución aquí: estoy usando Arch Linux con el escritorio Gnome; núcleo actual a partir de hoy: 4.16.
Recibí el mensaje
A stop job is running for Session c2 of user ... (1min 30s)
cada vez queRemote Login
estaba activadoSettings > Sharing
ySharing
estaba activado.Cada vez que desactivaba eso, mi computadora se apagaba bien usando el botón de apagado de Gnome.
Dado que "Inicio de sesión remoto" no es otra cosa que SSH, supongo que la respuesta de not2qubit también funcionará, porque deshabilitar NetworkManager probablemente también deshabilitará SSH.
fuente
A veces esto puede ser causado por una aplicación. Recordar los cambios realizados justo antes de que esto comience a suceder puede ser útil para determinar la causa. Tuve el mismo problema después de instalar
skypeforlinux-stable-bin
en Arch Linux. Cerrar esa aplicación antes de cerrar resolvió el problema (escribí una secuencia de comandos para hacer esto automáticamente antes de cerrar).fuente
Tuve este problema durante mucho tiempo, así que pensé en compartir mi solución.
El problema era que Google Chrome se ejecuta en segundo plano y no se cierra al apagar la computadora. Entonces, la mejor solución es desactivar esa función.
Esto lo resolvió para mí. Espero eso ayude.
fuente