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

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ó.

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

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! :)

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

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

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

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.

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

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".

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