Se está ejecutando un trabajo de detención para la sesión c2 del usuario

56

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 systemdversió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 c2lugar de dmesg, pero luego no hay nada en el shutdown-log.txt. He sustituido loginctl session-status c2por systemd-cglsy 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-ARCHy systemd 230-7, el error ya no ocurrió.

macnguyen
fuente
Desafortunadamente, la dmesgsalida 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).
n.st
1
Para verificar qué se está ejecutando en esa ominosa sesión c2 que no termina por sí sola, use 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 el loginctlcomando. Si no recibe un mensaje de inicio de sesión, siga los mismos pasos que usó dmesg, pero almacene el resultado de loginctl session-status c2. (Todo eso supone que siempre es "c2" lo que cuelga, no otra sesión cada vez).
n.st
1
Puede obtener una solución (temporal) con este truco: Crear /etc/sysctl.d/50-coredump.confcon contenido:, kernel.core_pattern=coreref: github.com/systemd/systemd/issues/1615#issuecomment-203507283
Runium
1
github.com/systemd/systemd/issues/2691 Esto puede ser relevante
Natecat el
2
@aurelien ¿Siempre es c2 lo que está causando que el temporizador se apague? Si es así, puede seguir diagnosticando problemas de apagado nuevamente y almacenar en loginctl session-status c2lugar de dmesg.
n.st

Respuestas:

45

Una solución a este problema es reducir este tiempo de espera /etc/systemd/system.confde 90 a, por ejemplo, 10 segundos:

DefaultTimeoutStopSec=10s

y ejecuta el siguiente comando en la terminal después de hacer cambios

$ systemctl daemon-reload
MightyPork
fuente
99
esto no explica ni resuelve el problema, también esperar 10 segundos y ni siquiera tener un apagado limpio no es nada bueno
jcora
¿Hay algún trabajo que tarde más de 10 segundos en detenerse?
Jared Chu
10

Este problema puede tener muchas causas, por lo que las respuestas específicas no funcionan demasiado bien. Pruebe esto para solucionar problemas:

  1. espere a que aparezca el mensaje "Se está ejecutando un trabajo de detención para la sesión c2 ..." al apagar y reinicie después de que se haya completado el apagado
  2. ejecutar journalctl -p5en una terminal y presionar ENDpara llegar al final del diario systemd ( -p5filtra mucha basura)
  3. comenzar una búsqueda presionando /e ingresar el término de búsquedatimed out. Killing.
  4. buscar hacia atrás presionando SHIFT+Nrepetidamente
  5. la línea debajo de cada coincidencia le indica qué aplicación se estaba portando mal:Killing 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! :)

mzuther
fuente
1
Gracias por esta respuesta correcta. Lo utilicé para encontrar que en mi caso las notificaciones "lpf" de Fedora 30 fueron la causa, y en lpf-gui deseleccioné Notificaciones | Permitir notificaciones.
vk5tu
5

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

Instalar watchdog

# pacman -S watchdog

Y luego inicie el servicio en el arranque:

# systemctl enable watchdog.service

Inicie el servicio para no ver más el mensaje.

# systemctl start watchdog.service

Creo una esencia para este https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

Diego Juliao
fuente
Seguí tu guía, pero no resuelve el problema. Gracias de todos modos.
macnguyen
2
¿Hay alguna otra implicación para esta solución? Aparentemente 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 si watchdogforzaría un reinicio en otras situaciones no deseadas.
Sparhawk
Leí tu página de manual . Creo que el perro guardián evita el reinicio diciéndole al kernel de Linux que todo está bien,
Diego Juliao
> Abre / dev / watchdog, y sigue escribiendo en él con la frecuencia suficiente para evitar que el núcleo se reinicie, al menos una vez por minuto.
Diego Juliao
Ningún paquete llamado watchdog en OpenSuSE, por lo que esto realmente no me ayuda :(
David Faure
4

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:

La solución es abrir el shell y "apagar ahora", luego, cuando la máquina vuelva a encenderse, realice un "reinicio" y el mensaje desaparecerá y los reinicios futuros ya no se bloquearán.

Usé "sudo shutdown now" y el retraso de reinicio ya no está. Parece demasiado simple, pero funcionó para mí (y para otros).

HTH

Dennis Cote
fuente
8
¿Por qué esta respuesta tiene tantos votos positivos? No funcionó para mí y no da idea de por qué debería funcionar.
Rodrigo
Funcionó para mí, pero aún no está claro por qué lo hizo.
pstryk
3

Habiendo tenido un problema similar en Kali [2017.01], con un retraso de cierre de sesión alternativo mostrado por

"Se está ejecutando un trabajo de detención para la sesión c1 del usuario Debian-gdm"

"Se está ejecutando un trabajo de detención para el Administrador de usuarios para el UID 132"

Logré eliminar un error deteniéndome primero NetworkManagerantes de apagarlo o deshabilitarlo, con:

# To get rid of: "A stop job is running for User manager for UID 132"
systemctl disable NetworkManager 
systemctl stop NetworkManager 

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 ), pulseaudioo dbus. Entonces, como no pude aislar el problema, la única forma era establecer las DefaultTimeout*Sec=5sentradas system.confcomo ya se mencionó en otras publicaciones.

Otros problemas que pueden investigarse se muestran en:

# systemctl --state=masked --state=not-found --state=failed

  UNIT                           LOAD      ACTIVE   SUB  DESCRIPTION                   
 tmp.mount                      not-found inactive dead tmp.mount                     
 auditd.service                 not-found inactive dead auditd.service                
 console-screen.service         not-found inactive dead console-screen.service        
 festival.service               not-found inactive dead festival.service              
 kbd.service                    not-found inactive dead kbd.service                   
 live-tools.service             masked    inactive dead live-tools.service            
 plymouth-quit-wait.service     not-found inactive dead plymouth-quit-wait.service    
 plymouth-quit.service          not-found inactive dead plymouth-quit.service         
 plymouth-start.service         not-found inactive dead plymouth-start.service        
 systemd-sysusers.service       not-found inactive dead systemd-sysusers.service      
 systemd-update-done.service    not-found inactive dead systemd-update-done.service   
 systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
 syslog.target                  not-found inactive dead syslog.target                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

y:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─user@132.service
 ├─pulseaudio.service
  └─739 /usr/bin/pulseaudio --daemonize=no
 ├─at-spi-dbus-bus.service
  ├─704 /usr/lib/at-spi2-core/at-spi-bus-launcher
  ├─709 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
  └─712 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
 ├─dbus.service
  └─694 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
 └─init.scope
   ├─597 /lib/systemd/systemd --user
   └─600 (sd-pam)
└─session-c1.scope
  ├─577 gdm-session-worker [pam/gdm-launch-environment]
  ├─613 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
  ├─618 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/132/gdm/Xauthority -background none -noreset -keeptty -verbose 3
  ├─697 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
  ├─721 /usr/bin/gnome-shell
  └─752 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
not2qubit
fuente
2
Esta respuesta al menos nos da información sobre cómo encontrar qué (de las muchas posibilidades) podría estar causando el problema en nuestras máquinas individuales. Otro problema es que después de poweroffo 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
duanev
2

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 que Remote Loginestaba activado Settings > Sharingy Sharingestaba 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.

stueja
fuente
1

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-binen 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).

prosoitos
fuente
0

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.

  1. Ve a la configuración de Google Chrome.
  2. Haga clic en "Avanzado".
  3. Vaya a "Sistema".
  4. Deshabilite "Continuar ejecutando aplicaciones en segundo plano cuando Google Chrome está cerrado".

ingrese la descripción de la imagen aquí

Esto lo resolvió para mí. Espero eso ayude.

ArianJM
fuente