☰

Apagado elegante con trabajo suspendido colgado en syscall

tag-icon • tag-icon linux kernel io suspend freeze
Apagado elegante con trabajo suspendido colgado en syscall

systemd-suspend.serviceCuando suspendí el sistema ayer, el trabajo no terminó y desde entonces tengo un trabajo suspendido en modo de suspensión ininterrumpida:

# systemctl list-jobs
  JOB UNIT                    TYPE  STATE  
21595 post-resume.target      start waiting
21593 systemd-suspend.service start running
21592 suspend.target          start waiting
21596 post-resume.service     start waiting

# systemctl status systemd-suspend.service
● systemd-suspend.service - Suspend
   Loaded: loaded (/nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/example/systemd/system/systemd-suspend.se>
   Active: activating (start) since Sat 2020-04-04 03:07:36 CEST; 23h ago
     Docs: man:systemd-suspend.service(8)
 Main PID: 16761 (systemd-sleep)
       IP: 0B in, 0B out
    Tasks: 1 (limit: 4915)
   Memory: 1.0M
      CPU: 20ms
   CGroup: /system.slice/systemd-suspend.service
           └─16761 /nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/lib/systemd/systemd-sleep suspend

Apr 04 03:07:36 phlegethon systemd[1]: Starting Suspend...
Apr 04 03:07:36 phlegethon systemd-sleep[16761]: Suspending system...

# ps aux |grep suspend
root     16761  0.0  0.0  10364  2052 ?        Ds   Apr04   0:00 /nix/store/2jspk70lir7jcn1krax8haw2j7486i3a-systemd-243.3/lib/systemd/systemd-sleep suspend

Cuando intento activar la suspensión manualmente, el kernel (5.4.14) responde EBUSY:

# echo mem >/sys/power/state
-bash: echo: write error: Device or resource busy

Parece que el kernel está bloqueado al sincronizar uno de los discos:

# cat /proc/16761/stack
[<0>] iterate_bdevs+0x98/0x142
[<0>] ksys_sync+0x6e/0xb0
[<0>] ksys_sync_helper+0x13/0x90
[<0>] pm_suspend.cold.8+0x213/0x361
[<0>] state_store+0x80/0xe0
[<0>] kernfs_fop_write+0xc1/0x1a0
[<0>] vfs_write+0xa5/0x1a0
[<0>] ksys_write+0x59/0xd0
[<0>] do_syscall_64+0x4e/0x120
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Ahora, en este estado, parece que ni siquiera puedo apagar la máquina normalmente:

# systemctl poweroff
Failed to power off system via logind: There's already a shutdown or sleep operation in progress

¿Entonces qué hago? Estoy tentado a utilizar el arma grande (Sysrq), pero me pregunto si realmente funcionará. sync(1)como era de esperar, simplemente se cuelga, por lo que soy reacio a intentarlo.

Además, ¿hay alguna manera de averiguarlo?cual¿Dispositivo de disco en el que está esperando el kernel? Espero que sea sólo algún dispositivo USB, nada grave.

Respuesta1

Sé que esto no responde exactamente a la pregunta, pero tal vez ayude un poco.
Tú u otra persona que leerá esto.

Tuve (o sigo teniendo) un problema similar ahora. Suspend no terminó de regresar al sistema con el trabajo colgado.

24913 systemd-suspend.service start running
24912 suspend.target          start waiting

Recibí el mismo mensaje que tú al intentar continuar.

# systemctl suspend
Failed to suspend system via logind: There's already a shutdown or sleep operation in progress


Mi objetivo era suspender, no cerrar. Aquí esta lo que hice.

# systemctl cancel
# systemctl stop systemd-suspend.service

Primero, detener la operación de colgar.
En segundo lugar, provocó que el sistema se suspendiera instantáneamente.

Después de cancelar, intenté suspender systemctl suspendpero el resultado fue el mismo problema nuevamente.
Después de despertar inicié el servicio, lo que ha suspendido el sistema nuevamente.

Con suerte, ahora podré suspender sin esta solución.

Respuesta2

Me encontré con problemas similares. Maté más de un día para encontrar la causa raíz de mi caso. Afortunadamente, esta fue una instalación de Ubuntu 20.04 de solo unas semanas de antigüedad, por lo que estuvo cerca de ser una instalación nueva.

Para mí, NetworkManager no se estaba ejecutando ni reiniciando ni nada similar después de iniciar sesión en el administrador de pantalla (sin cambios con respecto al valor predeterminado), por lo que no tenía acceso a WiFi.

También vi el equivalente de lo mencionado anteriormente:

# systemctl list-jobs
  JOB UNIT                    TYPE  STATE  
21593 systemd-suspend.service start running

Usar eso systemctl cancel 21593detendría el trabajo y solucionaría el problema, lo que demostró que ese era efectivamente el problema.

De man systemd-sleepencontrado

Inmediatamente antes de entrar en suspensión y/o hibernación del sistema, systemd-suspend.service (y las otras unidades mencionadas, respectivamente) ejecutará todos los ejecutables en /lib/systemd/system-sleep/... Todos los ejecutables en este directorio se ejecutan en paralelo. y la ejecución de la acción no continúa hasta que todos los ejecutables hayan finalizado.

Entonces, al examinarlo, /lib/systemd/system-sleepme di cuenta de que contenía scripts tlpque acababa de instalar. Desinstalé tlp y los paquetes asociados usando

sudo apt --purge remove tlp tlpui tlp-rdw

Y el problema desapareció por completo.

información relacionada