El mar, 30 mar 2021 a las 14:11, Carlos E. R. (
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hola:
(esta es para Rafa ;-) )
Llevo como un año mosqueado por un problema al intentar hibernar mi ordenador. Normalmente funciona perfecto, pero a veces se queda pillado y no progresa (y puedo arrancar programas tal cual). En esas ocasiones intento apagar el ordenador, y también se queda pillado. Incluso hago ctrl-alt-supr como 10 veces rápidamente: el kernel lo detecta y dice que ha detectado esas teclas siete veces en rápida sucesión, que entiende que es una emergencia y que actúa, pero no, no actúa. Tengo que dar el gran botonazo, y al día siguiente un gran fsck.
Hace poco puse "atop" en un terminal, y ví (cuando se trababa la hibernación) que decía que el disco sdc estaba al 100% ocupado. Iotop también pone algo interesante:
iotop:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 368.01 K/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 269.56 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 25530 be/4 root 0.00 B/s 332.85 K/s 0.00 % 97.58 % [kworker/u64:1+flush-8:32] <== 25104 be/4 root 0.00 B/s 4.69 K/s 0.00 % 1.41 % [kworker/8:1-events] 1408 be/3 root 0.00 B/s 11.72 K/s 0.00 % 1.25 % [jbd2/sdc10-8] 25944 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.04 % [kworker/0:2-events] 25637 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.04 % [kworker/0:0-events] 11191 be/4 cer 0.00 B/s 18.75 K/s 0.00 % 0.00 % firefox -P Small [localStorage DB]
atop:
PRC | sys 0.84s | user 1.73s | #proc 625 | #zombie 1 | no procacct | CPU | sys 10% | user 29% | irq 1% | idle 1065% | wait 96% | CPL | avg1 0.86 | avg5 0.45 | avg15 0.41 | csw 102167 | intr 58821 | MEM | tot 31.3G | free 13.2G | cache 2.8G | buff 1.4G | slab 1.2G | SWP | tot 100.0G | free 94.8G | | vmcom 29.4G | vmlim 115.7G | LVM | cr_cripta | busy 1% | read 0 | write 2 | avio 34.0 ms | DSK | sdc | busy 99% | read 0 | write 399 | avio 24.9 ms | <== NET | transport | tcpi 11 | tcpo 17 | udpi 0 | udpo 0 | NET | network | ipi 12 | ipo 17 | ipfrw 0 | deliv 12 | NET | eth0 0% | pcki 13 | pcko 18 | si 1 Kbps | so 1 Kbps |
PID SYSCPU USRCPU VGROW RGROW RUID EUID ST EXC THR S CPUNR CPU CMD 1/6 10990 0.06s 0.22s 0K 172K cer cer -- - 64 S 7 3% Web Content 10799 0.08s 0.19s 0K 0K cer cer -- - 81 S 5 3% firefox 11012 0.02s 0.23s 0K -84K cer cer -- - 60 S 8 2% Web Content 9585 0.03s 0.20s 0K 0K root root -- - 1 S 0 2% iotop 11096 0.04s 0.18s 1024K 1784K cer cer -- - 58 S 2 2% Web Content 4288 0.19s 0.00s 14356K 0K root root -- - 21 S 3 2% X
Lo siguiente era ver que partición de sdc era la ocupada; eso lo descubrí con gkrellm. Está escribiendo como 400K/S mantenidos, en la partición nueve.
/dev/sdc9 es reiserfs, y tiene varios montajes "bind":
/dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl)
montajes bind:
/dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl)
El directorio que está activo es "/var/spool/news". Uso leafnode nntp proxy server. Contiene 1.2 millón de ficheros en mas o menos 3 GB de espacio usado.
El siguiente descubrimiento es que si hago:
time sync time sync && systemctl hibernate
el sync puede tardar lo suyo, pero la hibernación es casi instantánea y no da problemas.
A partir de ahí descubrí que no es que la hibernación se quede trabada, es que el kernel intenta sincronizar los sistemas de ficheros, y no puede porque uno de ellos está constantemente escribiendo, y no consigue sincronizar hasta que el proceso termine, lo que puede tardar veinte minutos.
El proceso en cuestión es "texpire", que es disparado por el cron. Es un proceso que básicamente recorre todos los mensajes de las news uno a uno (que son 1.2E6 ficheros) para ver cual es muy antiguo y borrarlo.
Hay otra cosa muy rara, que es que cuando ejecuto "sync" fuera de esa franja de tiempo, tarda como un minuto en sincronizar. Un minuto de actividad de escritura en esa partición. Mi sospecha es que se trata de escribir las marcas de tiempo de los ficheros de mensajes leídos, que se hacen con retraso debido a "relatime,lazytime" (que son los parámetros por defecto).
Los viejos del lugar igual recuerdan que los servidores de noticias son uno de los pocos programas que usan las marcas de tiempo que registran la apertura de ficheros para leer.
¿Qué os parece?
La verdad es que yo no acostumbro a usar la hibernación, pero tengo una demora para el apagado, debido a un proceso de usuario 1.000 desde hace un par de meses con Tumbleweed. Para colmo, no puedo monitorizar que es lo que realmente pasa o cual es exactamente el proceso "que no quiere morir", porque el sistema está en proceso de apagado. Saludos, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/