Posté par needs .
En réponse au journal Le journal.
Évalué à 4.
journald
Journald me gêne car je ne souhaite pas avoir des logs en format binaire, je préfère parser avec des grep, cut, et autre outils texte, cela reste infiniment plus puissant que devoir passer par journalctl, d'autant plus qu'il s'agit ici d'une dépendance supplémentaire et systemd est une dépendance obligatoire de journald. En voici la raison :
Logging is a core part of service management. The journal is tightly integrated with the rest of systemd to ensure that everything in the system can be monitored, introspected and debugged. The generated journal entries are queried from various components in systemd. In effect systemd and journald are so tightly coupled that separating them would make little sense. That said, it’s Free Software, so you can do with the code whatever suits you. Finally, you are actually wrong in believing that systemd was an abomination.
(source, 1ère question de la FAQ) Les devs de LFS vont avoir du boulot…
Le fait d'avoir un format universel est plutôt intéressant, mais dans ce cas, juste avec du texte. Il y a aussi le problème de la sécurité mais je n'en connait pas les détails.
On peut tout de même ce poser des questions sur journald, que Lennart décrit comme :
Simplicity: little code with few dependencies and minimal waste through abstraction.
Par exemple il dit ici que l’outil doit être simple avec peu de dépendances, or systemd n'a rien d'une petite dépendance, de plus systemd est Linux only donc journald aussi. Ce qui veut dire que les applications devront avoir 2 solutions de log pour être un minimum portable. C'est bien évidement une très mauvaise approche.
Autre approche
On peut aussi prendre le problème des logs d'informations avec une autre approche :
En C, il y a 3 flux ouvert par défaut : stdin, stdout et stderr, le dernier est utilisé pour les erreurs. On pourrait ainsi créer un 4ème flux, stdlog ou stddbg par exemple pour prendre en charge les logs, puisque c'est essentiel pour une application de pouvoir communiquer son état et sa situation.
Il y aurait ainsi une entré /dev/stdlog et a chaque ligne ajoutée, le système s'occupe de rajouter les informations de temps, le PID, le nom de la machine …
On pourrait alors imaginer une utilisation tels que celle-la :
Que l'on pourrait manipuler ensuite de cette manière grâce aux redirections de flux :
$ firefox 3>> firefox.log
$ firefox 3>> firefox.log 2>&3 # Redirige aussi les erreurs vers les logs
Ou encore …
Puisqu'une raison d'être de journald est la non standardisation des logs, pourquoi ne pas proposer à la communauté une ébauche de standard ? Cela a en plus été déjà fait pour les logs server !
# Autre approche
Posté par needs . En réponse au journal Le journal. Évalué à 4.
journald
Journald me gêne car je ne souhaite pas avoir des logs en format binaire, je préfère parser avec des
grep,cut, et autre outils texte, cela reste infiniment plus puissant que devoir passer parjournalctl, d'autant plus qu'il s'agit ici d'une dépendance supplémentaire et systemd est une dépendance obligatoire de journald. En voici la raison :(source, 1ère question de la FAQ) Les devs de LFS vont avoir du boulot…
Le fait d'avoir un format universel est plutôt intéressant, mais dans ce cas, juste avec du texte. Il y a aussi le problème de la sécurité mais je n'en connait pas les détails.
On peut tout de même ce poser des questions sur journald, que Lennart décrit comme :
Par exemple il dit ici que l’outil doit être simple avec peu de dépendances, or
systemdn'a rien d'une petite dépendance, de plus systemd est Linux only donc journald aussi. Ce qui veut dire que les applications devront avoir 2 solutions de log pour être un minimum portable. C'est bien évidement une très mauvaise approche.Autre approche
On peut aussi prendre le problème des logs d'informations avec une autre approche :
En C, il y a 3 flux ouvert par défaut :
stdin,stdoutetstderr, le dernier est utilisé pour les erreurs. On pourrait ainsi créer un 4ème flux,stdlogoustddbgpar exemple pour prendre en charge les logs, puisque c'est essentiel pour une application de pouvoir communiquer son état et sa situation.Il y aurait ainsi une entré
/dev/stdloget a chaque ligne ajoutée, le système s'occupe de rajouter les informations de temps, le PID, le nom de la machine …On pourrait alors imaginer une utilisation tels que celle-la :
Que l'on pourrait manipuler ensuite de cette manière grâce aux redirections de flux :
Ou encore …
Puisqu'une raison d'être de journald est la non standardisation des logs, pourquoi ne pas proposer à la communauté une ébauche de standard ? Cela a en plus été déjà fait pour les logs server !