2014-11-21 10:45 GMT+00:00 Santiago Vila <[email protected]>: >> 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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/caejqa5lsdl8tpogk+ydy8p05ltqx5hpfk4+nckbvh1hv4t4...@mail.gmail.com
