Re: Pues sí, systemd se queda
2014-11-21 10:45 GMT+00:00 Santiago Vila <sanvila@unex.es>:
>> Tercero: "No hay consiguiente". Tú has probado el systemd (probarlo de
>> verdad, no instalado en un laptop para navegar por Internet y demás),
>> lo mismo que las veces que yo he he intentado hacer una paella de
>> marisco. Ninguna.
>
> Con lo de "no hay consiguiente" lo único que he querido decir es que
> el argumento de "almacenamiento binario" implica "corrupción de datos" me
> parece engañoso, pues las bases de datos mysql también se guardan en
> binario (aunque se consulten con órdenes SQL) y no pasa absolutamente nada.
>
> Si se produce corrupción de datos será por algún bug que haya, no
> simplemente "porque los logs se guarden en binario". Al ejemplo de
> mysql me remito.
No necesariamente. Puede ser causa de otras cosas como por ejemplo una
alta carga de un server en un espacio definido y acotado en el tiempo.
Algo así los engines de BBDD actuales lo tienen resulto, systemd no:
perderá los datos directamente si trabaja en memoria. Y más que un
bug, es un problema de diseño de la morralla en cuestión.
>
>> Cuarto: Vaya journald.conf es la solución a mis problemas. Ja. ¿Que
>> docs has leido tú?
>
> Pues journald.conf(5) para empezar.
>
>> ¿journald.conf me libra de la pérdida o corrupción de los logs
>> binarios?. Mentira.
>
> Estás mezclando pérdida y corrupción. La corrupción sería un bug.
La corrupción puede y puede que no sea un bug. Te he dado un ejemplo arriba.
>
> La pérdida de datos, en el ejemplo que has puesto, se ha producido
> porque el journal está en RAM y no puede ni debe crecer indefinidamente
> porque se te acabaría la RAM y algo hay que dejar para el resto del sistema.
Mismamente.
>
> Para que el journal sea persistente lo que puedes hacer, y seguramente
> en tu caso te conviene, es crear el directorio /var/log/journal. Si el
> servicio "systemd-journald", al iniciarse, ve que ese directorio existe,
> entonces los logs del journal van ahí y no a /run/log/journal.
Pues no, y no me dá la gana por el sencillo motivo porque para eso
tengo a "dos bestias" que se llaman rsyslog y syslog-ng que lo hacen
muy pero que muy bien y no pierden datos a menos que haya problemas de
hardware. ¿Por que tengo que redundar tareas y complicarlas si este
tema hace años que lo tengo resuelto con esos dos componentes?
La otra que también hay es que journald hace "casque" desde el momento
que le empiezan a entrar más de 12k EPS. Error oficial reportado en
Oracle.
Es otro ejemplo de hasta donde se quiere llevar a systemd y donde se
lo van a comer con patatas ...
>
> Por supuesto, no digo que esto resuelva todos los problemas que tengas
> con systemd, pero creo que tener el journal en disco duro es una
> posibilidad que se debería considerar.
>
Ni pienso. Ni systemd ni journald ni ninguno de los componentes
asociados está a la altura de lo que se exige en arquitecturas de
servidor.
Aquí el problema de verdad es que se están creando múltiples problemas
nuevos de algo que hacía años Unix tenía resulto y muy bien resulto.
De hecho estos problemas de journald, son los mismos que arrastraban
las ediciones Windows Server de Microsoft con su event viewer, que
según me comentaron, por fin consiguieron medio resolverlo con Windows
2008 R2/2012 R2.
Saludos.
Reply to: