[opensuse-es] [Resuelto?] Demora en el arranque por escritura de coredump
Saludos paso a describir este asunto y a explicar por que puse [Resuelto?] Al arrancar el sistema, se comenzaba a demorar. Haciendo esc en el boot. sale el mensaje: a start job is running for Flush Journal to Persistent Storage Tuve cierto problema con ark hace unos días pero fue nada serio. Hice la búsqueda encontré esto: https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta... Resumiendo la explicación, medidas para controlar los coredumps y no sean largos. Luego pasó a una observación a BTRFS que es responsable de la demora. =| Me quede con la manera práctica y borré /var/log/journal/<carpeta> Reinicio el sistema y parece ser que ya no habrá problemas. Llama la atención que de un asunto de coredumps pase a un asunto del mantenimiento del disco /etc/cron.weekly/* La discusión comienza más o menos aquí: https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta... =) Y nada más. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 21 de abril de 2018, 18:21, Carlos Ayala
Saludos
paso a describir este asunto y a explicar por que puse [Resuelto?]
Al arrancar el sistema, se comenzaba a demorar. Haciendo esc en el boot. sale el mensaje:
a start job is running for Flush Journal to Persistent Storage
Tuve cierto problema con ark hace unos días pero fue nada serio. Hice la búsqueda encontré esto:
https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
Resumiendo la explicación, medidas para controlar los coredumps y no sean largos. Luego pasó a una observación a BTRFS que es responsable de la demora. =|
Me quede con la manera práctica y borré /var/log/journal/<carpeta>
Reinicio el sistema y parece ser que ya no habrá problemas.
Llama la atención que de un asunto de coredumps pase a un asunto del mantenimiento del disco /etc/cron.weekly/*
La discusión comienza más o menos aquí: https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
Si existen coredumps, es porque hay cuelgues. Habría que buscar el motivo de esos cuelgues. Salu2 -- 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/ -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 2018-04-22 14:33, Juan Erbes wrote:
El día 21 de abril de 2018, 18:21, Carlos Ayala <> escribió:
Saludos
paso a describir este asunto y a explicar por que puse [Resuelto?]
Al arrancar el sistema, se comenzaba a demorar. Haciendo esc en el boot. sale el mensaje:
a start job is running for Flush Journal to Persistent Storage
Tuve cierto problema con ark hace unos días pero fue nada serio. Hice la búsqueda encontré esto:
https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
Resumiendo la explicación, medidas para controlar los coredumps y no sean largos. Luego pasó a una observación a BTRFS que es responsable de la demora. =|
Me quede con la manera práctica y borré /var/log/journal/<carpeta>
Reinicio el sistema y parece ser que ya no habrá problemas.
Llama la atención que de un asunto de coredumps pase a un asunto del mantenimiento del disco /etc/cron.weekly/*
La discusión comienza más o menos aquí: https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
Si existen coredumps, es porque hay cuelgues.
Habría que buscar el motivo de esos cuelgues.
A veces no se pueden evitar. Dependes de que algún programador se meta a resolverlos, y si no quiere, pues no puedes hacer nada. A mi el kodi se me cuelga con frecuencia. A veces vuelca core, a veces no. A veces, como hoy, me tirado todo el ordenador, he tenido que hacerle reboot por ssh. Y otra aplicación que necesito y que no es libre también se cuelga, y no puedo hacer nada al respecto. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On 2018-04-21 23:21, Carlos Ayala wrote:
Saludos
paso a describir este asunto y a explicar por que puse [Resuelto?]
Al arrancar el sistema, se comenzaba a demorar. Haciendo esc en el boot. sale el mensaje:
a start job is running for Flush Journal to Persistent Storage
Tuve cierto problema con ark hace unos días pero fue nada serio. Hice la búsqueda encontré esto:
https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
Resumiendo la explicación, medidas para controlar los coredumps y no sean largos. Luego pasó a una observación a BTRFS que es responsable de la demora. =|
Me quede con la manera práctica y borré /var/log/journal/<carpeta>
Reinicio el sistema y parece ser que ya no habrá problemas.
Pero eso es un remedio temporal.
Llama la atención que de un asunto de coredumps pase a un asunto del mantenimiento del disco /etc/cron.weekly/*
La discusión comienza más o menos aquí: https://forums.opensuse.org/showthread.php/527630-System-takes-longer-to-sta...
=) Y nada más.
Me llama la atención otra cosa, y es el miedo que tiene ese hombre a hacer cosas como root. Pánico. Y miedo tanbién a que le baneen en el foro por decir que ha hecho algo como root y a lo mejor se ha cargado en el sistema (al parecer, ya le banearon en el pasado). Lo digo porque sé que los administradores de ese foro te echan la bronca si le dices a alguien que haga algo como root, y más si ese particular comando y combinación de opciones se puede hacer como usuario. Pobre hombre. Incluso en consola te dicen que entres como usuario y luego hagas "su", en vez de entrar directamente como "root", cuando ahí precisamente da igual. No se si ahora le dicen a la gente que haga sudo para todo :-( Bueno, al asunto. Parece ser que el sistema de vez en cuando hace un asentamiento del journal, y eso lleva tiempo si es grande. Y sospecho que el arranque se detiene en ese punto porque no puede escribir cosas nuevas en el diario hasta que termine la operación. Y si estás usando btrfs pues hay otras complicaciones. Por otro lado, los volcados de núcleo (coredumps) cuando está en medio systemd se centralizan. Se pueden guardar dentro del propio journal, o en un directorio asociado. Y además, pueden estar comprimidos, lo cual es muy lento si el volcado es grande. Y el sistema los borra automáticamente pasado un tiempo (una semana, creo). El comando para ver el listado es "coredumpctl list" (que en mi caso lista unos 402 (si, cuatrocientos he dicho) desde agosto pasado. Sólo tres están guardados. Se configuran en "/etc/systemd/coredump.conf" El primer ajuste que hace el sistema es en el fichero virtual "/proc/sys/kernel/core_pattern", que el systemd lo pone a una tubería: cer@Isengard:~> cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e A partir de ahí el systemd-coredump captura el volcado que le manda el kernel, y lo guarda en /var/lib/systemd/coredump - en mi caso:
cer@Isengard:~> l /var/lib/systemd/coredump/ total 1453960 drwxr-xr-x 2 root root 413696 Apr 23 03:42 ./ drwxr-xr-x 9 root root 4096 Mar 15 10:20 ../ -rw-r-----+ 1 root root 73728 Apr 23 02:59 core.Kodi_MovistarTV.1000.f2375dd3b74f475aad32d93da55d3322.5453.1524445157000000 -rw-r-----+ 1 root root 1073741824 Apr 22 04:49 core.kodi\x2ebin.1000.61c4e543e90e4416b92c497d34acdc70.21221.1524365352000000 -rw-r-----+ 1 root root 414597120 Apr 23 03:42 core.kodi\x2ebin.1000.f2375dd3b74f475aad32d93da55d3322.5490.1524447767000000 cer@Isengard:~>
Una de las cosas que dicen es hacer: du -sh /var/log/journal/ para ver el tamaño del diario, y si es grande le pasan la aspiradora: journalctl --vacuum-time=2d Las opciones posibles son: --vacuum-size=, --vacuum-time=, --vacuum-files= Removes archived journal files until the disk space they use falls below the specified size (specified with the usual "K", "M", "G" and "T" suffixes), or all journal files contain no data older than the specified timespan (specified with the usual "s", "min", "h", "days", "months", "weeks" and "years" suffixes), or no more than the specified number of separate journal files remain. Note that running --vacuum-size= has only an indirect effect on the output shown by --disk-usage, as the latter includes active journal files, while the vacuuming operation only operates on archived journal files. Similarly, --vacuum-files= might not actually reduce the number of journal files to below the specified number, as it will not remove active journal files. --vacuum-size=, --vacuum-time= and --vacuum-files= may be combined in a single invocation to enforce any combination of a size, a time and a number of files limit on the archived journal files. Specifying any of these three parameters as zero is equivalent to not enforcing the specific limit, and is thus redundant. Yo tengo un tamaño de dos gigas de diario. Sí, dos gigas. La máquina es un pequeño servidor casero y servidor de multimedia, no se apaga nunca. No he notado problemas (el arranque es rápido). Tengo entradas desde el 20 de agosto pasado. Se configura en "/etc/systemd/journald.conf", y yo lo tengo todo por defecto. El tamaño de lo que guarda se configura con estas variables: SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values. The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. La partición es de 20 gigas, y un 10% es 2 gigas. Ese es el tamaño máximo. De vez en cuando tiene que pasar el log diario a permanente. Porqué no me da problemas ese tamaño? Pues porque es ext4 y está en un SSD... En realidad es que quería saber que pasaba con un log grande. Volcar el log a texto en un disco de óxido rotante tarda un disparate. Podéis perfectamente anular el journal. O que guarde solamente la sesión actual. O tener el log de verdad a la antigua, con syslog (yo recomiendo rsyslog). Sólo con borrar el directorio "/var/log/journal/" ya no guarda log permanente. Probablemente tengais estos scripts:
cer@Isengard:~> l /etc/cron.weekly/ total 16 drwxr-xr-x 2 root root 4096 Jan 25 15:24 ./ drwxr-xr-x 141 root root 12288 Apr 22 15:54 ../ lrwxrwxrwx 1 root root 44 Jan 25 15:24 btrfs-balance -> /usr/share/btrfsmaintenance/btrfs-balance.sh* lrwxrwxrwx 1 root root 41 Jan 25 15:24 btrfs-trim -> /usr/share/btrfsmaintenance/btrfs-trim.sh* cer@Isengard:~>
Y hacen cumplir estos ajustes: BTRFS_BALANCE_MOUNTPOINTS BTRFS_SCRUB_MOUNTPOINTS BTRFS_TRIM_MOUNTPOINTS que se guardan en "/etc/sysconfig/btrfsmaintenance". Yo, como no uso btrfs, no comento nada de ahí. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2018-04-23 a las 19:45 +0200, Carlos E. R. escribió:
On 2018-04-21 23:21, Carlos Ayala wrote:
Se configura en "/etc/systemd/journald.conf", y yo lo tengo todo por defecto.
El tamaño de lo que guarda se configura con estas variables:
SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.
The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either.
La partición es de 20 gigas, y un 10% es 2 gigas. Ese es el tamaño máximo.
De vez en cuando tiene que pasar el log diario a permanente.
Porqué no me da problemas ese tamaño? Pues porque es ext4 y está en un SSD... En realidad es que quería saber que pasaba con un log grande. Volcar el log a texto en un disco de óxido rotante tarda un disparate.
Podéis perfectamente anular el journal. O que guarde solamente la sesión actual. O tener el log de verdad a la antigua, con syslog (yo recomiendo rsyslog).
Sólo con borrar el directorio "/var/log/journal/" ya no guarda log permanente.
Esto hace que no guarde log - ni siquiera el de la sesión actual: /etc/systemd/journald.conf: [Journal] Storage=none SystemMaxUse=100M RuntimeMaxUse=30M MaxLevelStore=notice cer@minas-tirith:~> l /var/log/journal ls: cannot access '/var/log/journal': No such file or directory Pero si hacéis eso, instalar rsyslog para tener un registro clásico, no podéis estar sin ninguno. No usar syslog-ng, porque tira de los ficheros del journal, y como no existen, no tira. En cambio rsyslog funciona perfectamente, saca los datos de otra fuente más correcta en un sistema que usa systemd. - -- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlrePa4ACgkQtTMYHG2NR9XMhwCdEyE2BRlzmVhMn5mRRzm/aNmd VFcAn3czc9wYBLNjxboWAB7bDwLGzxjb =/xcw -----END PGP SIGNATURE-----
On Mon, Apr 23, 2018 at 3:10 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2018-04-23 a las 19:45 +0200, Carlos E. R. escribió:
On 2018-04-21 23:21, Carlos Ayala wrote:
Se configura en "/etc/systemd/journald.conf", y yo lo tengo todo por defecto.
El tamaño de lo que guarda se configura con estas variables:
SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values.
The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either.
La partición es de 20 gigas, y un 10% es 2 gigas. Ese es el tamaño máximo.
De vez en cuando tiene que pasar el log diario a permanente.
Porqué no me da problemas ese tamaño? Pues porque es ext4 y está en un SSD... En realidad es que quería saber que pasaba con un log grande. Volcar el log a texto en un disco de óxido rotante tarda un disparate.
Podéis perfectamente anular el journal. O que guarde solamente la sesión actual. O tener el log de verdad a la antigua, con syslog (yo recomiendo rsyslog).
Sólo con borrar el directorio "/var/log/journal/" ya no guarda log permanente.
Esto hace que no guarde log - ni siquiera el de la sesión actual:
/etc/systemd/journald.conf:
[Journal] Storage=none SystemMaxUse=100M RuntimeMaxUse=30M MaxLevelStore=notice
cer@minas-tirith:~> l /var/log/journal ls: cannot access '/var/log/journal': No such file or directory
Pero si hacéis eso, instalar rsyslog para tener un registro clásico, no podéis estar sin ninguno.
No usar syslog-ng, porque tira de los ficheros del journal, y como no existen, no tira. En cambio rsyslog funciona perfectamente, saca los datos de otra fuente más correcta en un sistema que usa systemd.
- -- Saludos Carlos E. R. (desde openSUSE 42.3 x86_64 "Malachite" en Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlrePa4ACgkQtTMYHG2NR9XMhwCdEyE2BRlzmVhMn5mRRzm/aNmd VFcAn3czc9wYBLNjxboWAB7bDwLGzxjb =/xcw -----END PGP SIGNATURE-----
Cuando salga la nueva versión de openSuSE, la 15: https://news.opensuse.org/2018/04/18/opensuse-leap-15-release-scheduled-for-... Me voy a cargar con gusto al BTRFS. >=( Ojalá y ya venga con NodeJS 8. =| -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (3)
-
Carlos Ayala -
Carlos E. R. -
Juan Erbes