Journald tiene una falla grave, la verdad que no admisible para sistemas en produccion critica. Si bien no voy a dar soporte a esta cosa, para los desdichados que lo usen, aca va el problema y un workaround, ademas de una mera opinion al respecto de "la cosa" en cuestion.
Como comenté anteriormente, systemd-journald tiene algunos problemas. Despues del día en que hice el PoC donde se ve como crashea el sistema, hubo una actualizacion de algunas cosas y eso al menos quedo solucionado, PERO, siempre hay un pero, el bug de que deja de loguear, persiste.
Es decir, pongamoslo asi:
Si por error, accidente, falla de hardware o que sos hackeado o simplemente subieron una shell y ejecutaron algo como borrar system.journal, te quedaste sin logs, en todo el sistema. Secure, Messages, Auditd, todos ellos dejan de recibir informacion porque claro, en realidad quien escribe esta informacion, es journald aunque rsyslog este corriendo y ahora les voy a mostrar porque.
La cosa, es que van a ver, que al poner systemctl status systemd-journald aparece en verde, como corriendo en su version 208-28, y todo ok, lo cual... es lo opuesto a lo que el idiota mal programador de Lennart dice, que systemd facilita la tarea de revisar servicios, dado que, nos miente, diciendonos que esta corriendo cuando, no lo hace, y como lo se? facil. Luego de que system.journal es borrado o corrompido, al poner journalctl -l van a ver que dice que no hay logs, estos tampoco se vuelven a regenerar de ninguna manera, por lo tanto, podemos quedarnos sin log por un largo tiempo hasta que notemos esto en journalctl y en los demas log tradicionales, por lo tanto, no se fien de systemctl, dado que segun parece, chequea mal los servicios, o sea, chequea que corren no que hacen su trabajo.
Journald detiene la escritura tras un borrado de su log, lo que es un bug claramente, no me jodan (sobre todo los de #systemd en freenode) con que es un feature, para poder saber cuando fuiste hackeado, dado que si funciona en conjuncion (como es por defecto en opensuse) con rsyslog, esto no ocurre, dado que rsyslog, sigue escribiendo y genera un nuevo user-1000.log (log del usuario no del sistema, es lo mismo, tambien registra los login)
Entonces, tenemos un journald fallado, que, deja de escribir todos los log del sistema (gravisimo) en caso de borrado o corrupcion, cual es la manera?, bueno tomar el archivo de journald.conf y setear que todo sea forwardeado a rsyslog, para que al detenerse journald tras el borrado o falla, este continue registrando accesos, errores, etc y de paso, regenera un nuevo system.journal, con la informacion de que un log anterior fue borrado, por eso digo que es claramente, un error de diseño en journald, que requiere de rsyslog para regenerarse y registrar que ha sido dañado, cosa que segun Lennart hacia solo y nos informaba, lo unico que hace solo es dejar de funcionar y asi informa?, mi dios, quien le enseño a programar a ese pibe? algun programador de VB 6.0.
Entonces, si usan CentOS 7 o Fedora en ambientes criticos, o no, modifiquen journald.conf para que todo sea forwadeado a rsyslog, sino, en caso de error se van a quedar sin logs en el OS completo.
Cual es mi critica?:
Tener dos demonios haciendo lo mismo, journald + rsyslog, dado que este ultimo suple las falencias de diseño del primero, pero, es realmente de mal programador hacer esas cosas y mas, si tenemos en cuenta que en 32 bit, en memoria journald ocupa algo de 7Mb, y rsyslog algo de 3Mb, por lo tanto en vez de tener 3Mb si el idiota de Lennart no se metia con el sistema de logueo, ahora tenemos 10Mb aprox, lo que nos da un desperdicio de 7Mb, diran, ay pero que amarrete este synflag no compra RAM, no, no es eso, es que en 7Mb en un entorno GNU/Linux, pueden correr una cantidad de programas que es larga la lista, o servicios, ni hablar de usar Pidora, la version de Fedora para ARM la cual usa systemd, 7Mb en ARM, es MUCHO o los que sean, es realmente una mierda tener que usar DOS cosas para el mismo fin, porque la NUEVA y moderna como dicen muchos, esta mal diseñada.
Como comenté anteriormente, systemd-journald tiene algunos problemas. Despues del día en que hice el PoC donde se ve como crashea el sistema, hubo una actualizacion de algunas cosas y eso al menos quedo solucionado, PERO, siempre hay un pero, el bug de que deja de loguear, persiste.
Es decir, pongamoslo asi:
Si por error, accidente, falla de hardware o que sos hackeado o simplemente subieron una shell y ejecutaron algo como borrar system.journal, te quedaste sin logs, en todo el sistema. Secure, Messages, Auditd, todos ellos dejan de recibir informacion porque claro, en realidad quien escribe esta informacion, es journald aunque rsyslog este corriendo y ahora les voy a mostrar porque.
La cosa, es que van a ver, que al poner systemctl status systemd-journald aparece en verde, como corriendo en su version 208-28, y todo ok, lo cual... es lo opuesto a lo que el idiota mal programador de Lennart dice, que systemd facilita la tarea de revisar servicios, dado que, nos miente, diciendonos que esta corriendo cuando, no lo hace, y como lo se? facil. Luego de que system.journal es borrado o corrompido, al poner journalctl -l van a ver que dice que no hay logs, estos tampoco se vuelven a regenerar de ninguna manera, por lo tanto, podemos quedarnos sin log por un largo tiempo hasta que notemos esto en journalctl y en los demas log tradicionales, por lo tanto, no se fien de systemctl, dado que segun parece, chequea mal los servicios, o sea, chequea que corren no que hacen su trabajo.
Journald detiene la escritura tras un borrado de su log, lo que es un bug claramente, no me jodan (sobre todo los de #systemd en freenode) con que es un feature, para poder saber cuando fuiste hackeado, dado que si funciona en conjuncion (como es por defecto en opensuse) con rsyslog, esto no ocurre, dado que rsyslog, sigue escribiendo y genera un nuevo user-1000.log (log del usuario no del sistema, es lo mismo, tambien registra los login)
Entonces, tenemos un journald fallado, que, deja de escribir todos los log del sistema (gravisimo) en caso de borrado o corrupcion, cual es la manera?, bueno tomar el archivo de journald.conf y setear que todo sea forwardeado a rsyslog, para que al detenerse journald tras el borrado o falla, este continue registrando accesos, errores, etc y de paso, regenera un nuevo system.journal, con la informacion de que un log anterior fue borrado, por eso digo que es claramente, un error de diseño en journald, que requiere de rsyslog para regenerarse y registrar que ha sido dañado, cosa que segun Lennart hacia solo y nos informaba, lo unico que hace solo es dejar de funcionar y asi informa?, mi dios, quien le enseño a programar a ese pibe? algun programador de VB 6.0.
Entonces, si usan CentOS 7 o Fedora en ambientes criticos, o no, modifiquen journald.conf para que todo sea forwadeado a rsyslog, sino, en caso de error se van a quedar sin logs en el OS completo.
Cual es mi critica?:
Tener dos demonios haciendo lo mismo, journald + rsyslog, dado que este ultimo suple las falencias de diseño del primero, pero, es realmente de mal programador hacer esas cosas y mas, si tenemos en cuenta que en 32 bit, en memoria journald ocupa algo de 7Mb, y rsyslog algo de 3Mb, por lo tanto en vez de tener 3Mb si el idiota de Lennart no se metia con el sistema de logueo, ahora tenemos 10Mb aprox, lo que nos da un desperdicio de 7Mb, diran, ay pero que amarrete este synflag no compra RAM, no, no es eso, es que en 7Mb en un entorno GNU/Linux, pueden correr una cantidad de programas que es larga la lista, o servicios, ni hablar de usar Pidora, la version de Fedora para ARM la cual usa systemd, 7Mb en ARM, es MUCHO o los que sean, es realmente una mierda tener que usar DOS cosas para el mismo fin, porque la NUEVA y moderna como dicen muchos, esta mal diseñada.
4 comentarios:
Buenos días.
Bro, de que forma puedo reparar upstart, pasa que reemplacé libc6 de forma manual y al parecer se rompió el init.
El grub arranca pero a la hora de iniciar el kernel, se reinicia la máquina
Gracias de antemano.
01010011 01100001 01101100 01110101 01100100 01101111 01110011
Lo que yo haria, es iniciar en modo live, hacer un chroot y reinstalar la libc, en este mismo blog en el post de como recuperar grub, estan los pasos para un chroot como si iniciaras el sistema.
Veo que eres uno de los pocos que realmente lo lleva claro. Menos mal. ;)
Me encanta testear las cosas, software, hardware, por eso el nombre del blog :)
Publicar un comentario