Bonjour
l'un des reproches fait au journal (outil de log de systemd) est l'utilisation d'un format binaire initialement non documenté et pour lequel aucune promesse de stabilité n'avais été faite :
https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs
Une partie de ces reproches est maintenant caduque puisqu'un document apparu hier sur le wiki de systemd documente en profondeur le format du journal : http://www.freedesktop.org/wiki/Software/systemd/journal-files
Le comportement que doit avoir un logiciel souhaitant lire ou écrire le journal sans passer par l'api de journald est également décrit.
Enfin, même si aucune promesse de stabilité n'est faite, un mécanisme d'extension compatible du format est là, ce qui laisse présumer d'une volonté de ne pas tout casser dans un futur proche.
# Promesse de stabilité
Posté par Misc (site web personnel) . Évalué à 10.
Visiblement, ça a été rajouté :
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart
Aussi bien le format binaire que le format d'export.
# Pourquoi du binaire
Posté par lolcat . Évalué à 2.
Pourquoi utiliser un format binaire contre un format texte standard ?
[^] # Re: Pourquoi du binaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Et bien c'est simple, c'est parce que 0101010110101010101110101.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi du binaire
Posté par Maclag . Évalué à 4.
Mainte fois discuté, tout comme de nombreuses questions autour de systemd. C'est une histoire de perfs et de souplesse.
Il y a un convertisseur de binaire en texte, et en fait, quand j'ai testé systemd, il remplissait les journaux "traditionnels" en parallèle avec ses journaux binaires, pour éviter un choc trop gros.
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 6.
C'est un peu expliqué dans le lien donné par le journal, sinon un moteur de recherche doit pouvoir te redonner les raisons.
Globalement, il y a des raisons techniques de complexité des algos pour la recherche, le stockage, etc, le fait de pouvoir avoir des indexes, etc. Par exemple, si tu veux pouvoir donner accès que à certaines metadonnées, avoir un format binaire sera plus rapide qu'une regexp pour trier tout ça ( et c'est sans doute la raison de la présence de plugin de log dans mysql/postgresql pour rsyslog ). Dans systemd, les infos affichés par systemctl status sont obtenus par le journal, et je pense qu'il est important d'avoir un accés indexé aux infos ( et pas relire les megaoctets de logs pour afficher les infos )
Ensuite, il y a le fait de vouloir pouvoir avoir du binaire dans les logs ( dump en cas d'erreur etc, etc ).
Il y a aussi des discussions sur http://lwn.net/Articles/468381/ , mais bon, vu qu'il suffit d'avoir rsyslog pour avoir les logs au format texte, j'ai du mal à voir le souci pour les gens.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 9.
Je sais pas, faudrait demander aux devs de MySQL pour leur db sont pas directement des fichiers textes avec les requêtes SQL ;)
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 5.
bah suffit de le faire en perl, ou est le problème :)
http://search.cpan.org/~hmbrand/DBD-CSV-0.36/lib/DBD/CSV.pm
( je l'utilise sur un script maison qui dumpe les offres de jobs, ça marche assez bien et je trouve ça drole de faire un select sur du csv, mais je précise que bien sur c'est pas une solution entreprise ready, ça supporte pas encore xquery )
[^] # Re: Pourquoi du binaire
Posté par needs . Évalué à -5.
Car les base de données c'est une manière d'organiser des fichiers. Les FS traditionnels stockent les fichiers selon une arborescence, les bases de données selon des tables et des relations entre elles.
On pourrait très bien imaginer un système de fichiers qui utilise le modèle relationnel pour stocker ces données. Donc c'est normal que MySQL et consorts utilise leur propre format.
journaldet MySQL ne sont donc pas comparable.[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1.
Bon, vu que tu n'as pas trouvé, je vais te donner la réponse: pour des raison de performance…
Les fichiers textes c'est tellement bien qu'autour de moi tout le monde utilise un logiciel propriétaire pour faire des recherches dans ses logs: splunk.
D'ailleurs si quelqu'un connait un équivalent de splunk libre et bien foutu, je prend.
[^] # Re: Pourquoi du binaire
Posté par needs . Évalué à -4. Dernière modification le 21 octobre 2012 à 17:09.
C'est une conséquence indirecte, évidemment qu'un système de fichier doit être performant.
[^] # Re: Pourquoi du binaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
http://kibana.org/ ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi du binaire
Posté par Moonz . Évalué à 6.
En même temps les logs, les performances en lecture sont assez secondaires, alors que c’est assez primordial pour une base de données. Par contre pouvoir lire un log avec un simple busybox fonctionnel ça me semble une fonctionnalité importante, alors que pour une base SQL on s’en fiche un peu.
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 5.
Tu viens d'expliquer pourquoi ils utilisent leur propre format et non pourquoi ils utilisent un format binaire.
Il y a le problème de la performance : un log ça peut être gros (tu peux chercher sur plusieurs semaines si tu as envie), les log binaires sont plus petits (les écritures aussi sont plus petites donc on charges moins les buffers noyau) et la recherche y est plus performante. Il y a aussi une question de fiabilité. La recherche par expression rationnelle a des limites (les séparateurs peuvent se trouver n'importe où).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Si, si, ils peuvent utiliser un format texte
http://dev.mysql.com/doc/refman/5.1/en/csv-storage-engine.html
Mais je suis entièrement d'accord que ce n'est pas la question >.<
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à -5.
Mauvais admin, changer admin !
Aller, tiens, c’est cadeau :
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 6.
Et ?
On parle de chercher sur plusieurs semaines. La rotation ne change rien au problème : il faut tout de même chercher dans ces archives.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 1.
Je sais pas ce que vous avez comme serveurs, mais sur les miens, très très peu chargés, les logs compressés font déjà 10 MB par jour (apache est bien verbeux pour juste dire qu'une IP a accédé à une page). Sur un serveur "normal", ça donnerait plutôt 500 Mo/jour, soit 200 Go/an (minimum légal + un peu de marge, 366 c'est léger, tu te prends une demande judiciaire le samedi pour la même date 1 an avant, faut que tu te loggues pendant ton WE pour pas perdre le log).
Une fois décompressées, pour ta recherche sur plusieurs semaines (car la demande n'est pas précise), tu peux te retrouver avec 1 To de log "texte", et grepper la chose, ben ça prend du temp.
Et au final, je ne vois pas le rapport entre ton cadeau et son commentaire, un bon admin devra quand même chercher sur plusieurs semaines si on le lui demande.
Alors oui, je ne sais pas de combien journald réduit la chose, mais toute réduction de taille est la bienvenue.
[^] # Re: Pourquoi du binaire
Posté par Moonz . Évalué à 6.
Je doute qu’un format binaire te fasse gagner grand chose relativement à du texte compressé.
À moins que ton logiciel de compression soit particulièrement mauvais.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 0.
Les logs de journalctl sont compressé par défaut donc tu gagnes (certe rien) pour le log courant :p
Journal récupère les infos en O(log(n)), alors que grep nécessite de tout parser… O(n), c'est surtout cela qui est important.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 0.
Journal récupère les infos en O(log(n))
Les infos qu'il a indexé hein. Pas forcément les infos que tu veux. Pour les infos qui sortent des clous c'est du O(n) aussi.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1.
Mais de quoi tu parles, t'en a pas marre de raconter n'importe quoi ?
O(log(n)) c'est tout le temps, y'a pas d'indexeur dans journald…
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
O(log(n)) c'est tout le temps, y'a pas d'indexeur dans journald…
Mais oui, il cherche parmi n éléments pour un élément spécifique en O(log(n)) le tout sans index, et ce y compris sur le contenu des éléments du journal.
Tu es au courant que ça n'est pas mathématiquement possible ?
Bien entendu journald indexe tous les champs ou presque (de façon générale tous les champs qui commencent par _ (donc les champs de confiances) sont indexés).
Tu veux faire une recherche sur un autre champ ? Ben tu te prends un O(n) dans la gueule (ce qui est une fois de plus tout à fait normal).
Mais de quoi tu parles, t'en a pas marre de raconter n'importe quoi ?
Je m’entraine avec des pro, donc je me lasse jamais.
[^] # Re: Pourquoi du binaire
Posté par brendel . Évalué à 0.
va falloir définir ce qu'est n alors… Parce que chercher parmi n éléments sans aucune info sur leur organisation en O(log(n)), y'a pas besoin de réfléchir longtemps pour voir le soucis… On dirait des commentaires à la Apple : "j'ai rien regardé mais comme c'est systemd c'est forcement mieu !"
[^] # Re: Pourquoi du binaire
Posté par Littleboy . Évalué à 3.
C'est un peu la qu'est le souci. J'ajouterais que lire la documentation ne serait pas un mal pour eviter d'affirmer avec aplomb le contraire de ce qu'il y a dedans et passer pour un con.
[^] # Re: Pourquoi du binaire
Posté par brendel . Évalué à 0.
Je ne l'ai pas lue, ça ne change rien. Il y a forcement soit une indexation soit une opération assimilé (en gros stockage d'infos à partir d'une analyse) pour obtenir une recherche en log(n).
Ou alors les éléments que l'on peut rechercher sont dotés de propriétés intéressantes, mais il ne me semble pas que ce soit le cas des logs?
[^] # Re: Pourquoi du binaire
Posté par brendel . Évalué à 1.
Au fait, tu aurais pu expliquer, au moins quitte a passer pour un con j’apprends quelque chose :)
[^] # Re: Pourquoi du binaire
Posté par Littleboy . Évalué à 1.
Pardon c'etait pas tres clair, mais mon commentaire s'applique aux memes personnes que le tien (j'en rajoute une couche, quoi).
On est en fait parfaitement d'accord.
[^] # Re: Pourquoi du binaire
Posté par Tom . Évalué à 1.
Voir ici, partie "Advanced Filtering"
Cela semble répondre à vos questions (et vous donner raison).
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 1.
Mauvais lecteur, changer de lecteur.
Si tu cherche sur un mois, tu aura 30 fichiers compressé à analysé, ce qui peut être gros.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par needs . Évalué à 4. Dernière modification le 21 octobre 2012 à 15:55.
Parce que Lennart n'a toujours pas comprit l'intérêt d'Unix. L'interface texte toussa …
Les mauvaises langues me diront qu'il y a une commande
grepd,catd,cutd, … Ou encore une commande pour traduire le format dejournalden texte. Mais ou est l'intérêt, ou ??La place ? Les logs chez moi ne font même pas 50Mo, et
journaldest inutilisable sur un serveur car il est dépendant desystemd.On ne peut pas stocker des données binaires ? Normal, ce n'est pas leur place. Le reste, c'est comme un code source : il faut faire un choix entre maintenabilité/lisibilité et rapidité.
Lennart expose ses raisons dans cet article (1er lien du journal). Ces critiques sur le système actuel sont parfois pertinentes, comme le problème de la sécurité des logs et l'authentification des processus. Vous remarquerez aussi que cette page contient une liste des qualités de
journald, je vous recommande de la lire : elle montre que l'approche de Lennart manque de recul sur l’existante.[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 9.
C'est bien connu, aucune distribution (comme Suse ou Red Hat) qui tourne sur un serveur n'envisage de passer à systemd.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 7.
C'est bien connu, aucune distribution (comme Suse ou Red Hat) qui tourne sur un serveur n'envisage de passer à systemd.
Je pars du principe que ton commentaire est ironique mais cependant si on regarde les deux grosses distribs payantes (Red Hat et Suse Entreprise LInux) on a pas grand chose.
Il y a vaguement une slide de juin pour RH7 dans la section "truc qu'on envisage". Et depuis plus rien du tout la dessus. (Mais alors rien de chez rien)
OpenSuse est passé à systemd, mais leur page officielle de status sur systemd fait un peu peur, la page bugzilla aussi ( https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=systemd ) et du coup la page disant que Suse Entreprise Server allait passer sur systemd a carrément été retiré du net (publié le 15 octobre, encore présente sur toolinux dans le cache google mais introuvable).
Quand à Debian qui reste quand même l'OS non payant le plus populaire pour des installations professionnelles, il ne semble pas super pressé de changer.
Donc pour l'instant les grosses distribs serveurs envisagent, mais de loin. Apparemment les clients payants sont tous des réactionnaires effrayés par le changement. (En tout cas une partie suffisamment importante d'entre eux le sont, au point que les grosses distribs payantes ne communiquent plus sur Systemd).
Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.
Après la prochaine fournée devrait arriver en 2013 (début pour Suse, milieu pour RH) et il peut se passer pas mal de chose entre temps. Ceci dit il y a quand même un problème à ne pas passer en systemd : les distro de "test" que sont Fedora et OpenSuse, elles, ont franchit le pas. Donc ca va pas simplifier le freeze/debug tout ça.
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 10.
Je pense que ta maitrise de l'anglais doit te jouer des tours, car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire, ouais, peut être.
Et donc pour que tout le monde puisse juger de tes sources, j'invite les gens à voir les fameux vagues slides sur :
http://rhsummit.files.wordpress.com/2012/03/burke_rhel_roadmap.pdf , voir la conf sur
http://videos.cdn.redhat.com/2012-summit-bestof-04.ogg , vers la 37eme minute.
Mais j'aurais tendance à dire qu'il y a d'autres choses qui font penser que systemd va se retrouver dans RHEL 7, comme :
https://github.com/openshift/origin-server/blob/master/broker/openshift-origin-broker.spec
Notons les lignes 13 et consorts :
%if 0%{?fedora} >= 16 || 0%{?rhel} >= 7
%define with_systemd 1
%else
%define with_systemd 0
%endif
Pour les non initiés aux rpms, ça définit une variable "with_systemd" qui est utilisé par la suite dans le fichier pour savoir si on embarque un fichier .service ou un script d'init. Notons l'idiome "si la valeur de la variable fedora est supérieur ou égale" à 16, suivi de "ou si la variable rhel est supérieur ou égale à 7", laissant supposer que pour une fedora supérieur à 16 ou une rhel supérieur à 7, systemd serait utilisé ( je laisse le reste du fichier spec à titre d'exercice ).
Sachant que le fichier spec est celui utilisé par le projet openshift, projet lancé par RH, et que les commits sont fait par des gens de la boite, on peut donc supposer qu'ils ont fait des déductions un chouia plus éclairé que les tiennes, basés sur des informations un chouia mieux sourcés ( au moins concernant le produit de leur employeur ).
On peut aussi regarder ailleurs, par exemple, en prenant au hasard des checkouts qui traineraient sur le disque ( ce qui est mon cas ), et tomber sur :
http://pkgs.fedoraproject.org/cgit/abrt.git/tree/abrt.spec
La, on voit une construction un chouia plus complexe avec le contre intuitif bcond_without ( qui rajoute l'option pour désactiver une option, donc qui l'active par défaut ), et le fait qu'il y a aussi des unités systemd prévu dans un paquet pour RHEL 7.
Ou on peut aussi aller en prendre au pif parmi les paquets Fedora maintenus par des gens de RH, comme au hasard, libvirt :
http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec#n145
Un commentaire court mais sans équivoque.
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet, je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH qui ont dit "faut pas mettre systemd, kaane m'a dit que ça pue".
Sinon, tu noteras en pratique que ni Suse, ni Red Hat ne communique pour le moment sur la sortie des produits tout court, ou sur aucune feature. Red Hat en a parlé lors de sa conférence annuelle, et Suse a du faire pareil et basta.
Est ce que ça veut dire qu'ils vont abandonner toutes les fonctionnalités du monde ? Non, je crois pas.
La ou tu vois une défiance envers systemd ( ie, la ou tu interprète les faits pour ne pas remettre en cause ta vision myopique de la chose ), je vois juste du bon sens de ne pas faire de foin sur un version de leurs distributions qui ne sont pas encore fini.
Suse a visiblement un cycle de 3 ans, mais on peut supposer que le rachat et la réorganisation de Novell par Attachmate a pu fortement perturbé ça, ce qui laisse encore du temps pour une release en 2013. ( mais bien sur, tu peux sans doute continuer à croire que systemd a totalement tout mis en l'air, et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même )
D'ailleurs, quand je vois la page du bugzilla sur le kernel, je me demande si Suse ne va pas abandonner linux, car bon, ça fait peur, y a 200 bugs ouverts :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=kernel
Ou lacher yast ( 167 bugs ) :
https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=openSUSE+12.2&content=yast
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 4.
Tu es bien gentil de fournir tant d'arguments (la, pour le fichier spec, c'est clair, net, précis…), moi il me suffit déjà de regarder qui paye le salaire du développeur pour savoir au moins pour une distrib!
En tous cas, bravo pour autant d'efforts, il y a 10x plus de preuves que nécessaire pour Red Hat (pour Suse, va falloir attendre, mais je suis prêt à mettre un pari dessus)
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 10.
car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire,
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet
Surtout que tout ton argumentaire repose sur le fait qu'il fasse leurs études et tests sur Fedora, chose que j'ai signalé dans mon post au fait. Et que donc il va leur être difficile de na pas mettre systemd dans RH 7 (ce que j'ai dit aussi).
je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH
Ben justement non j'en ai aucun. Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support (payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Or le truc c'est que dans le milieu professionnel les "c'est évident" et les "ca se voit" on a tendance à s'en méfier pas mal. (Surtout avec RH à qui ca ne fait pas peur de faire passer à la trappe une techno du jour au lendemain).
_ et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même_
OK. Donc tu n'as juste pas compris le problème en fait.
En dehors des utilisateurs qui utilisent Linux pour s'amuser et s'instruire, il y a des sociétés (parfois même des grosses sociétés) qui utilisent Linux pour traiter des données sensibles, des fois vitales à la boite, dans leur activité de tous les jours. Ces sociétés ne représentent pas une portion très importante des utilisateurs de Linux, par contre elles représentent 100% des clients payant de boites comme RH ou Suse.
Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet, prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats etc.)
Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd. Et ils n'en veulent pas parce que :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont pas possible avec systemd.
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de l'utilisabitlité du bigniou par des sysadmins.
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
Ah oui, je donne la liste mais j'ai oublié de dire qu'il fallait lire :
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une solution mais elle est trop complexe pour être backportée
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un fichier de lock qui traine dessus. COOOL
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse quelqu'un ? )
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Après tu fais comme tu veux, mais moi ce genre de bugs sur des trucs que j'utilise couramment (pas comme le timer du device machin sur une architecture ARM spécifique que l'on ne retrouve que sur des téléphones portables hackés) ca me fait peur.
L'init doit être le process le plus robuste qui soit. C'est lui le centre névralgique du système. Si il bugue on ne peut plus rien faire. L'init est presque plus importante que le kernel au niveau debug (une bonne init peut permettre de comprendre ce qui a chié dans le kernel, la réciproque n'est pas vraie).
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 8.
la même chose, à savoir que tu piges de travers l'anglais comme ça t'arrange, et que tu t'arrêtes juste à ce que tu crois être vrai ( comme montré par les autres trucs que j'ai posté )
Alors pour quoi tu nous prends pour des truffes en disant :
"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd"
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait, on laisse la relation client aux commerciaux ( ensuite, peut être que tu as bossé dans des boites différentes ). Bien que je ne soit pas juriste, je pense qu'il y a des gens qui craignent que ce genre de réponse soit "legally binding", et que ces gens sont plus juristes que toi et moi.
Je suis sysadmin, c'est marqué sur mon contrat de travail et j'ai un serveur face à moi qui tourne avec systemd ( en mageia 2 ). Techniquement, je peux te sortir d'autres sysadmins, d'autres serveurs, ce qui fait qu'on pourras passer au pluriel.
Mais c'est sans doute pas assez rigoureux comme preuve, y a sans doute des tests pour dire "la, il arrive à s'en servir".
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd. Quand à backporter la feature, c'est sans doute parce que la politique est la même qu'ailleurs, à savoir juste les bugfixes, pas les features. Et la, c'est une feature ( à savoir un type de service "idle" )
Tu as lu de travers. C'est plus "si quelqu'un a encore un file handle ouvert, alors on peut pas démonter le fs". Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant. Pour débugguer ce genre de souci, il y a plusieurs façon. Tu peux utiliser le système de bootchart ( histoire d'avoir un graph détaillé ), tu peux avoir le graph des dépendances. En pratique, le mode pas à pas, ça va rarement servir à débloquer des soucis autre que "tel soft ne se lance pas, il faut que je le passe".
Mais le bug parle de systemd.confirm_spawn, qui va faire grosso modo la même chose que "press I for interactive mode" du boot classique d'un RH. Ensuite, visiblement, il y a un certain nombre de bugs corrigés upstream, et je ne doute pas que Frederic va tester et backporter si besoin.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs. Au passage, ça marche sans souci avec automount sur Mageia.
Je ne peux que redire "si c'est marqué systemd quelque part, ça veut pas dire que c'est un souci de systemd". En l'occurrence, quelqu'un a rempli le systéme monté en ramfs sur un livecd ( donc avec aufs ). Donc l'oom killer a fini par tuer tout les process, en terminant par le pid 1. Comme dit dans le bug report, tu t'attends à quoi ? La backtrace est une backtrace kernel, le message est "kernel panic".
Donc sur les 5 bugs que tu donnes, il y a :
1 bug qui n'est pas un bug systemd mais le comportement normal du kernel
1 bug qui vient du script d'init nfs et d'un mauvais ordre pour les divers choses à lancer
1 bug ou la feature existe, mais possède des bugs corrigés dans la versions récentes de systemd
1 bug ou systemd se comporte comme les init classiques, due à un bug plymouthd
1 bug corrigé dans les versions récentes de systemd pour les gens qui utilisent nis, un port série et qui veulent pas attendre
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Ok respect, ça rends le produit totalement inutilisable d'avoir 2 bugs que le dev d'opensuse n'a pas eu le temps de backporter. En aucun cas ça va être prêt pour une release qui n'est pas encore annoncé, et en aucun cas ça va marcher sur tout les autres cas ( genre ceux ou tu as pas des ports séries avec du nis )
Je terminerais sur tes 3 boites avec sysadmins ( un échantillon donc statistiquement représentatif, et bien sur, aucunement influencé par toi, surtout au vue de ta propension à sortir des trucs crédibles sauf quand on creuse plus de 30 secondes ) et donc :
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ? J'ai loupé les émeutes qu'il y a du y avoir à ce sujet mais bon, c'est la même chose non ?
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests ( sauf bien sur pour les horreurs homegrowns dont tu as parlé la dernière fois ).
En effet, c'est à dessein pour certains. Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible. Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle. Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué pour dire "regarde, dans ce cas totalement trop compliqué, je sais pas comment faire mais j'ai pas le droit d'en dire plus, donc ça invalide tout"
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ? Le seule chose vraie qu'on peut dire, c'est que sysvinit était "fini" dans le sens ou il y avait plus d'évolution dessus. Normalisé, systemd suit la LSB, donc les scripts d'init doivent marcher encore. Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 4.
Alors pour quoi tu nous prends pour des truffes en disant :
_"il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd" _
C'est dans leur distribs betas, c'est dans le code des paquets mais ça n'est officiel nul part. Comment tu interprètes toi qu'un papier qui dit que Suse Entreprise Server utilisera systemd soit retiré ?
Le truc c'est que soit ils ont décidé de mettre systemd quoi qu'il arrive, mais qu'ils tiennent absolument à nous faire la surprise (ce que tu as l'air de penser), soit ils ne sont pas sur de mettre systemd.
Le support ne parle jamais des produits en cours de développement, et c'est pareil dans toutes les boites que j'ai fait,
Et dans la plupart des cas j'en ai rien à faire. Mais dans le cas présent si il faut porter tous les scripts d'init custom j'aimerai pouvoir commencer en avance. Maintenant je ne suis pas categoriste, si le support n'a pas le droit de répondre, je prend la réponse de n'importe qui d'officiel à la place. Seulement cette réponse (à l'heure actuelle) je ne l'ai pas.
Le fait que Solaris soit passé à smf est la preuve qu'on peut survivre à un changement de système d'init.
J'ai aucun problème avec un changement d'init. J'ai un problème majeur avec systemd. SMF est une réussite et si on pouvait avoir un truc pareil sous Linux je ferais des bonds de joie. Les points forts de SMF sont :
- Tout un système basé quasi exclusivement sur les templates : tous les services sont des templates, et on peut facilement créer et détruire des instances à la volée en changeant les paramètres de configuration ou en dupliquant une instance existante.
- Des dépendances ultra-réduites. Pas besoin de ramener une pléthore d'outils pour que ca marche.
- Un grand respect de l'existant : les scripts de rc.d/* continuent d'être executés. inittab est toujours parsé etc.
- Un système turing complet avec des vrais outils pour manipuler l'environnement d’exécution des services aussi bien avant le démarrage que pendant l’exécution.
Et pléthore d'autres trucs qui font cruellement défaut à systemd.
Si on se logue trop tôt et qu'on utilise NIS. Et comme tu dit, c'est corrigé dans une nouvelle version systemd.
Le problème n'est pas là. Le problème est comment une interaction de ce type peut-elle tromper l'init et le faire se comporter de façon nocive pour le système ? Un getty crashe (ca peut arriver), ben on le relance.
Ce qui est le comportement standard de sysvinit et de tout les autres. Et d'après le bug, c'est plymouthd qui bloque.
Une fois de plus le problème n'est pas la. Que /var ne se démonte pas parcequ'il est locké OK, mais pourquoi au reboot systemd devient-il incapable de monter /var ? Je n'ai jamais eu d'erreur de type 'ah non, il y a un fichier de lock alors j'interdis le montage' sur sysinit ou sur bsdinit. Comment un fichier à la con peut-il empêcher /var de monter ?
Que le fichier vienne de plymouth on s'en fout.
Un boot pas à pas dans un système prévu pour lancer les choses en même temps est ma foi un concept des plus intéressant.
Au hasard parce que justement comme le système n'est pas prédictif, j'aimerais bien pouvoir lancer B avant A pour voir ce qui se passe. Par exemple si j'ai un bug qui se produit une fois sur 5 ou 6 et que je pense que c'est la fois ou le service TUTU se lance avant le service TOTO qui est normalement toujours premier à s'executer. Là pour faire ce genre de tests il faut que je fasse dépendre artificiellement TOTO de TUTU (et bien entendu que je remette les trucs dans le bon ordre si c'est pas ça). Si j'ai trois ou quatre hypothèses je vais me marrer.
C'est pas un souci de systemd, c'est un souci de nfs sur Suse, et Fedora 18 propose les unités pour nfs.
Non. C'est bien un manque de systemd (pas un problème à proprement parlé, mais un comportement inattendu) que l'on peut contourner. Les sockets virtuels foutent la grouille entre les différents process de NFS et comme automount part très vite on est obligé de broder un peu pour que ypbind et autofs soient actifs et en forme pour de vrai au moment ou automount vient les chercher.
Comme dit dans le bug report, tu t'attends à quoi ?
Tu es en train d'insinuer que c'est un comportement normal de tuer l'init quand un disque ram est plein ? Comme dit le bug report une ligne plus bas, je m'attends plutôt à ce que l'on arrive sur un refus genre "disque plein" avec des retry et des purges (enfin comme sur n'importe quel autre fs quoi).
Donc je compte 2 bugs déjà corrigés, 2 bug à corriger ailleurs ( nfs, plymouthd ), et 1 "why did you expect".
Donc bien 5 bugs, des trucs qui peuvent se produire et qui explosent l'init.
Et les corrections ne sont pas coté systemd (genre ah oui, dans ce cas dégénéré là ca empêche l'init - c'est embêtant quand même) mais coté des outils. Genre ok le logiciel de haut niveau TOTO a planté l'init, mais c'est de sa faute il a pas fait les appels comme il faut et c'est corrigé dans la version 4.2 du logiciel TOTO.)
Le problème est que le logiciel de haut niveau TOTO ne devrait pas pouvoir planter l'init. Pas du tout. Bordel c'est l'init ! Ca doit être bétonné.
Comme avec chaque version majeur. Est ce qu'ils ont eu des tonnes de boulot avec upstart sur les RHEL 6 ?
Grosso modo upstart ca a foutu la grouille dans les configs TTY à la con et les runlevels custom, mais c'était pas bien méchant au final. Ne serait-ce que parce qu'on avait toujours les scripts et l'environnement.
Sinon, quand tu payes la souscription RHEL ou SLES, c'est aussi pour que le distributeur fasse les tests
Le distributeur il t'aide en cas de pépin et il peut débugguer des trucs pas évident. Mais il n'a pas un clone de ton install chez lui. Donc pour faire les tests…
Le mot de passe à l'init, une riche idée quand le systéme est sequentielle car ton serveur se bloque en attendant de rentrer le mot de passe, c'est pas du tout fragile au possible.
Les trucs qui dépendent du mot de passe sont nécessairement bloqués (en fait c'est même le but d'un mot de passe) - Les trucs qui ne dépendent pas du mot de passe continuent. Quand il y a plusieurs mots de passe, pour s'y retrouver on affiche un texte explicatif (Genre veuillez rentrer le mot de passe pour le certificat truc de l'instance apache www.example.com )
Je pense au passage que c'était pas possible non plus avec upstart qui dans mon souvenir lance les trucs en parallèle.
Si si, ça marche très bien. Parce que upstart execute des scripts et sait mettre les demande d'interaction utilisateur à la queue leu leu.
Quand aux templates, j'ai deja du dire que ç'est prévu par systemd, et la dernière fois, tu as sorti un exemple super compliqué
Un truc super compliqué : une variable d'environnement dont le contenu n'est pas fixe.
Un autre truc super compliqué : le résultat de l’exécution d'un autre service.
Heureusement ça arrive rarement les service qui donne des résultats ou les variables d'environnement qui changent.
Formidable ça. Parce que upstart ou l'init classique sysinit, c'était normalisé ?
Non mais c'était turing complet. Donc on pouvait TOUJOURS trouver une solution ou un contournement.
Bie sur, tu va trouver sans doute des cas de scripts hors lsb qui ne marche pas, et dire "bah ça marche pas".
Il y a des scripts d'init full LSB qui ne marchent pas. Pour les partitions chiffrées notamment.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à -1.
Wow…
Il y en a qui s'y mettent 2 ans après la sortie d'une version (le plus classique)
Il y en a qui s'y mettent dès la sortie d'une version (ça se voit un peu)
Il y en a qui s'y mettent pendant les betas d'une version (encore plus rare)
Mais je découvre qu'il y en a qui s'y mettent alors que le produit n'est même pas en alpha. Ou alors c'est du bluff, juste pour troller et inventer des critiques quand il n'y en pas.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 10.
Il y en a qui s'y mettent 2 ans après la sortie d'une version (le plus classique)
Au risque de me répéter : C'est l'init.
C'est pas programme dans un coin que je peux utiliser ou pas, upgrader ou pas. En RHEL 6 il y a pleins de trucs que je n'utilise pas, comme networkd, SELinux, les outils graphiques etc. mais il y a des trucs très récents que j'utilise (typiquement on a la dernière version de kvm/libvirt).
La question n'est donc pas "est-ce qu'on prend ou est-ce qu'on ne prend pas ?" mais "est-ce qu'on se repositionne par rapport à RHEL ou pas ?".
Même si on décide de ne pas passer en RHEL 7 (pour cette raison, ou pour d'autres) on a au minimum 3 ans pour changer. Après on rentre en "production 2" et ça peut poser des soucis. Mais trois ans pour faire les tests, choisir un remplaçant, valider la nouvelle archi et la faire certifier c'est pas non plus la fête. On est confortable, mais pas trop.
Là pendant à peu près un an (jusqu'à la première beta) on va être dans le noir. Donc on peut dire qu'on aura deux ans de marge. Sans être tendu ça va commencer à être un peu serré.
Donc oui, j'aimerai avoir les infos maintenant. Ne serait-ce que pour préparer la direction à accepter que le budget 2014 soit plus conséquent que les années précédentes (que l'on reste avec RHEL ou pas d'ailleurs).
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à -7.
Kaane: patron, 2014, faut un budget plus grand, car RH a changé son init et il pue, faut donc changer de distro
Patron: ah? Pourquoi l'init pue
Kaane: j'ai aucun argument qui tienne la route, on me rit au nez quand j'en parle, mais si si il pu
Patron: bon, c'est vraiment parce que j'ai la flemme de chercher un admin qui a plus d'arguments, admettons
Kaane: patron, 2017, faut un budget plus grand, car notre nouvelle distro a changé son init et il pue. Vous vous rappelez d'il y a 3 ans? ce salaud a réussi à pourrir toutels les distros maintenant, faut donc changer de distro mais pour une distro très très ancienne, donc beaucoup de budget pour beaucoup de maintenance perso car personne veut se farcir le boulot de maintenance de mon init adoré
Patron: Il faut donc changer d'admin plutôt
Rassure-moi, tu n'es quand même pas en train d'essayer de me dire que tu choisis une distro en fonction de son système d'init?
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 2.
Ca tombe bien, systemd a un mode de compatibilité sysvinit… Mais bon, un script d'init rc qui fonctionne entre deux versions d'une distribution sans modification, c'est déjà pas gagné, surtout sur des gros logiciels.
Cool, ben il va falloir que ces boites pensent à les foutre à la porte alors, parce que bon, les vieux croutons qui refusent d'apprendre parce qu'ils ont toujours fait comme cela, en informatique, on sait ce que ca donne…
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 10.
Ca tombe bien, systemd a un mode de compatibilité sysvinit
Qui a de grosses lacunes, on en a déjà discutés plusieurs fois.
Cool, ben il va falloir que ces boites pensent à les foutre à la porte alors, parce que bon, les vieux croutons qui refusent d'apprendre parce qu'ils ont toujours fait comme cela, en informatique, on sait ce que ca donne…
Elles ont plutôt tendances à foutre à la porte les jeunots qui savent mieux et qui installent la dernière version sans réfléchir (parce que c'est forcément mieux). Ce sont eux qui font des dégats que les vieux croutons doivent réparer.
[^] # Re: Pourquoi du binaire
Posté par groumly . Évalué à -8.
Mouais, de ce que j'en vois, ceux qui se font virer c'est plutot ceux qui refusent la mouvance devops et t'expliquent que des centaines de lignes de shell distro specific pour un truc aussi con que lancer un service, c'est mieux et c'est la voie d'unix, la vraie.
Et ceux que je voient arriver et qui font du bon boulot, c'est soit des developeurs qui s'y connaissent bien en admin sys ou des admin sys qui sont suffisament malins pour apprendre a developer.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 0.
Et le jour ou le vieux crouton par à la retraite, elles s’aperçoivent qu'elles ont 20 ans de retard…
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 3.
Et t'as déjà fait des recherches dans des logs sur autre chose que ton pc personnel avec grep et compagnie ? Réponse: ca rame comme la mort, tu peux facilement attendre 5 minutes pour t'apercevoir que ton grep ne renvoie rien et recommencer pour 5 minutes de grattage de disque supplémentaires.
Avec journald, les recherches sont rapides et c'est pour cela que le format binaire est intéressant.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 7.
Avec journald, les recherches sont rapides et c'est pour cela que le format binaire est intéressant.
Aucun rapport.
On peut parfaitement normer et indexer un fichier texte.
La raison pour laquelle une recherche dans les logs prend du temps est l'absence de format prédéfini et l'absence d'index. Si tu en mets un des deux (ou encore mieux les deux) tu peux avoir d'excellentes performances.
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 6.
On peut, mais par defaut, ça ne le fait pas.
Donc ouais, "on peut coder tel truc", sauf que quand il s'agit de faire autre chose que de poster sur linuxfr, y a plus personne.
[^] # Re: Pourquoi du binaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Clique sur page perso de temps en temps, tu verras qu'il y a beaucoup de gens en charge d'un ou plusieurs projets libres.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 21 octobre 2012 à 18:16.
Mais alors, pourquoi personne ne l'a donc fait?
Faut croire que ce n'est pas si facile…
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire (ben oui, ASCII.UTF-8 c'est du binaire aussi, juste pas du tout normé et dont il faut 100 octets à la place de 10 pour décrire la même chose exactement), ça a l'air vachement dur pour certains admins de juste changer de commande pour l'afficher à l'écran, sacré résistance au changement…
Pourquoi c'est pas fait?
Pourquoi rajouter encore plus de volume de données pour faire la même chose?
chez vous les disques durs sont gratos?
Vous avez quoi comme utilisateurs sur vos machines pour avoir que 50 Mo de logs? Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" qui résout tous les reproches fait au avant sans supprimer un seul avantage du avant à part la mémoire de l'admin qui connait déjà ses commandes.
Bougez vous le cul et proposez une pratique à votre théorie, plutôt que troller sur LinuxFr qui ne montre que votre résistance au changement (ah non : ça montre aussi que vos idées ne sont que du vent). En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…
Dès qu'il faut faire quelque chose et confronter sa théorie à la pratique, oh plus personne…
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 9.
Mais alors, pourquoi personne ne l'a donc fait?
SQLLite ? Par exemple hein, il y en a un paquet d'autres (Pas mal de backends LDAP par exemple)
De façon générale il existe une palanquée de "flat file database" dans lequel le bianire est l'exception plutôt que la règle.
PS : jamais compris pourquoi des gens arrivent à se braquer sur un format "binaire" pour défendre un autre format binaire
Oui en vrai tous les formats sont binaires. Surprise il n'y a pas de petits caractères en fonte dans les processeurs. Et pourtant on fait le distinguo.
Un indice : Lisible facilement par un être humain et éditable facilement avec des outils standards.
Pourquoi c'est pas fait?
Sur les systèmes qui en ont besoin, c'est fait.
Mes logs DNS/Apaches sont indexés par exemple.
Pourquoi rajouter encore plus de volume de données pour faire la même chose?
chez vous les disques durs sont gratos?
Parce qu'un meta en INT LE 64 bits ça ne prend pas de place ?
Le format ASCII prend de la place mais le format binaire c'est gratuit ?
Au risque de te surprendre, le fait que les disques durs ne soient pas gratuit est une excellente raison de ne pas mettre :
- 12 000 métas sur des entrées ou ca n'apporte pas grand chose
- Une nouvelle palanquée d'outils pour lire et trier ces métas
- D'autres outils pour gérer la corruption des données (oui en ascii la corruption d'un octet ca peut faire chier mais pas plus que ça, alors qu'en binaire)
- Et bien sur toute la clique de convertisseurs pour les programmes qui ne parlent pas encore le journald couramment (et dont même en cherchant bien on ne voit pas pourquoi ils apprendraient à le faire)
_ Il y a des gens qui ont des Go de log (surtout sur 1 an, minimum légal), et remercie journald et son format "binaire avant c'était pas binaire" _
1) Personnellement j'ai des Go de logs par jour. Avec des scripts baysiens pour foutre à la poubelle ce qui n'a pas d’intérêt et ne stocker que le nécessaire.
2) Je ne connais personne qui a des Go de logs à maintenir et qui dise merci au format binaire. Pourtant du sysadmin j'en connais - mais même ceux qui sont éventuellement intéressés par journald sont rebutés par le fait qu'il faille rameuter systemd et toute la clique pour que ça marche.
sans supprimer un seul avantage du avant
A part la non lisibilité par un humain, le surplus de maintenance, le coté non standard/non fini, la non intégration dans l'existant, les dépendances, la fragilité à la corruption etc.
_ En attendant, il y en a un qui se bouge le cul, lui, et il a l'air de bien répondre à un besoin de beaucoup de monde…_
Tant mieux pour eux. Bon je ne connais pas ce "beaucoup de monde" là. Le beaucoup de monde que je connais est plutôt contre systemd - mais bon il en faut pour tous les gouts. Je ne suis pas développeur système, ni mainteneur de packages. Je suis architecte et sysadmin - et pour l'instant je ne vois que des inconvénients à systemd et les avantages de journald (qui existent c'est clair) ne sont pas suffisant loin s'en faut pour que je reconsidère systemd comme une possibilité.
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 3.
SQLite utilise un fichier binaire, merci de confirmer ce que les autres disaient.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
SQLite utilise un fichier binaire, merci de confirmer ce que les autres disaient.
Le header et la numérotation des lignes est en binaire. Le contenu est en flat - c'est entre autre ce qui permet le typage dynamique des colonnes.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1.
C'est exactement pour cela que personne ne sérieux ne penserai à utiliser sqlite pour avoir des vraies performances… Suffit de voir la différence de rapidité au niveau de la gestion des collections entre Amarok (mysql) et Clementine (sqlite).
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 3.
Y a surtout que sqlite supporte pas les accès concurrents. J'ai tenté sur puppet, ça monte pas des masses en charge ( genre à partir de 7/8 clients, ça fait de la merde, on monte à plus de 300 fois plus au taf avec mysql )
[^] # Re: Pourquoi du binaire
Posté par Anthony Jaguenaud . Évalué à 0.
Là, tu sous entend qu’avec amarok je suis obligé d’utiliser une base
mysql. Ouf, heureusement que chez gentoo, ils ont patché à mort, et même réécrit amarok pour éviter de démarrer un serveurmysqlsur ma machine de bureau…En fait, pour ton information, on peut installer amarok sans
mysqlsur toute les bonnes distro. Ce n’est pas la cas sousArch? (Je sais, on est pas vendredi, mais c’était tentant ;-) ).[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 2.
Ça doit effectivement être le cas car je n'ai pas vu l'option du choix de SGBDR depuis qu'ils sont passé à la version 2 (y compris sous Gentoo).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est un peu l'inverse, amarok 1 n'avait que sqlite.
Amarok 2 supporte MySQL et Postgres de manière officiel et le backend Qt/SQLite est totalement non supporté par les devs.
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 3.
Je ne vois pas où le choix de Postgres est possible dans la configuration https://www.claudex.be/owncloud/public.php?service=files&file=/claudex/files/Public/sc_amarok.png
Sinon, je me souviens bien que MySQL et Postgres étaient disponible dans Amarok 1.4, il y a d'ailleurs encore de la documentation sur le sujet http://amarok.kde.org/wiki/Amarok_1.4/User_Guides/PostgreSQL_HowTo
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 22 octobre 2012 à 11:29.
Et si tu coches pas, alors amarok lance un mysql configuré sur ton $HOME.
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 3.
Je ne vois pas où ça parle de postgres sur ton image.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1.
Effectivement, j'ai confondu avec Akonadi… Mais je parlais pas de postgres au départ ;)
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 3.
Je répondais juste au commentaire qui disait qu'Amarok prenait en charge d'autres SGBDR que MySQL.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Anthony Jaguenaud . Évalué à -2.
Je n’ai pas dit cela. J’ai dis qu’on pouvait utiliser amarok sans mysql… ce que grumk a prouvé avec sa copie d’écran. Je réagissais parce que grumk voulait prouver que mysql était plus rapide que sqlite en comparant deux applications différente sans prendre en compte leur propre spécificité. S’il voulait faire un test de bench entre les deux, encore faudrait-il avoir des exemples comparables.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 22 octobre 2012 à 13:05.
C'est vrai que ce n'est pas comme si Clementine c'était le code de Amarok 1.4… Je veux bien que les devs d'amarok soit des pros de l'optimisation des requetes SQL mais faut pas pousser non plus…
De plus, non, ma capture d'écran prouve qu'on doit utiliser Amarok avec MySQL…
Une explication d'un dev d'Amarok sur pourquoi ils ont abandonné sqlite…
http://amarok.kde.org/blog/archives/812-mysql-in-amarok-2-the-reality.html
[^] # Re: Pourquoi du binaire
Posté par Anthony Jaguenaud . Évalué à 1. Dernière modification le 22 octobre 2012 à 13:10.
Excuse-moi, j’ai mal vu, mais j’ai cru voir une case à cocher sur ta capture d’écran, ce qui me fait bêtement penser que ça se désactive, donc qu’on ne doit pas, mais qu’on en a la possibilité si on le désire. En plus, pour le péquin moyen, ajouter un serveur mysql sur son ordi de bureau… plus gérer la connexion… j’installe GNU/Linux sur les ordis de mes proches pour pas avoir à les maintenir.
Tu compares donc amarok 1.4 a amarok 2… c’est effectivement la même chose.
Édit: Ajout de « En plus (…) maintenir. »
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 4.
Ce que montre la copie d'écran, c'est la possibilité d'utiliser une base MySQL externe au lieu de MySQLembedded, il n'est pas du tout question de SQLite ou d'un autre SGBDR.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 2.
La cache à cocher n'est pas « désactiver » mais « use external database » : on te propose d'en utiliser une externe plutôt que celle interne.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Anthony Jaguenaud . Évalué à -1.
Et donc ? Si on la décoche ? Il faudrait lire ce qui est écrit. Je répète :
Grumk : amarok doit utiliser mysql.
Moi : Non, il y a une case à cocher.
Toi : (voir ci-dessus)
À moins que la base par défaut soit une base mysql, sinon, je ne vois pas.
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 4.
La base par défaut est une base MySQLembedded mais il possible d'utiliser une base qui tourne sur un vrai système MySQL (en locale ou distant).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 1.
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-sound/amarok/amarok-2.6.0.ebuild?view=markup
En plus tu racontes n'importe quoi, amarok utilise mysql aussi sous Gentoo…
Et tu me fais dire des conneries, c'est akonadi qui a un support sqlite non officiel, pas amarok…
[^] # Re: Pourquoi du binaire
Posté par Anthony Jaguenaud . Évalué à -2.
Je m’en fais dire aussi. Mon propos initial était que tu sous-entendais l’obligation d’utiliser mysql. Ce qui est faux. Et je réagissais parce que je n’ai pas de serveur mysql sur mon PC. Donc, qu’amarok n’a pas besoin de mysql pour fonctionner.
[^] # Re: Pourquoi du binaire
Posté par Albert_ . Évalué à 2.
amarok n’a pas besoin de mysql pour fonctionner.
Comme prouve au dessus. Malheureusement si… Cela me pose d'ailleurs un probleme de savoir que j'ai besoin d'un truc comme MySQL pour ecouter de la musique…
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 5.
Si tu as juste besoin d'écouter de la musique, tu utilise un bazooka pour tuer une mouche. Il y a des outils bien plus simple pour ça, comme Dragon Player.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Misc (site web personnel) . Évalué à 6.
Être flat, ça veut rien dire. Tout au plus, on parle de flat file, et la, je propose de regarder :
http://www.sqlite.org/fileformat.html
à comparer avec
http://en.wikipedia.org/wiki/Flat_file_database
Sqlite utilise un arbre binaire ( b-tree ) pour accéder à des enregistrements ( records ). C'est pas exactement la définition de wikipedia. Donc sauf à dire "oui, c'est plat sauf la ou c'est pas plat", je pense que tu es dans l'erreur.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Sqlite utilise un arbre binaire ( b-tree ) pour accéder à des enregistrements ( records ).
Oui.
Ca s'appelle un index.
Ca permet de savoir à quel endroit de quel fichier se trouve l'information.
Donc ils ont indexés des fichiers majoritairement texte.
Et ils ont mis des métas aussi.
C'est ce dont on parle.
Enfin je crois…
Mais apparament je parle le klingon.
Et encore, peut-être qu'en klingon je me ferais mieux comprendre.
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 4.
L'index binaire est stocké dans le même fichier que le "texte" (qui au final est juste un ensemble de strings C dumpées telles quelles dans un fichier binaire), c'est donc de facto un fichier binaire.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 3.
L'index binaire est stocké dans le même fichier que le "texte" (qui au final est juste un ensemble de strings C dumpées telles quelles dans un fichier binaire), c'est donc de facto un fichier binaire.
Donc si je résume on ne peut pas indexer ou rajouter des metas à un fichier texte, parce que si on le fait il devient de facto un fichier binaire ?
C'est impossible, mais on va le faire et quand on aura fini ça ne sera plus un fichier texte qu'on aura indexé ?
Et si on met l'index à coté (genre un index séparé sur une base de données type mbox, le container mail) ca compte ou pas ?
Et si il y a des pièces jointes en base64, le fichier il est binaire ou pas ?
Non sérieusement les gars. Si je fais un less de mon fichier de données SQLite, j'ai du charabia qui s'affiche ou je peux voir mes données ?
[^] # Re: Pourquoi du binaire
Posté par groumly . Évalué à -3.
On dit pas que c'est pas faisable, on dit juste que:
1) c'est un montage de bouts de ficelles avec une vis en travers pour faire tenir le tout,
2) ca scale pas. SQLite c'est cool pour des petits sets de donnees, accedes sequentiellement et/ou pour des donnees vraiment pas critique et reconstructibles, l'utiliser pour autre chose, c'est de la folie douce
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du binaire
Posté par Thomas Debesse (site web personnel) . Évalué à 10.
et si je répond
Yj'obtiens un truc aussi (il)lisible que si j'avais essayé d'ouvrir un exécutable contenant plein de chaînes de caractères en dur !C'est pas parce que tu peux faire
strings mon_fichier_sqlite.dbque tu es en présence d'un fichier texte. Tout ce que tu es en train de démontrer, c'est que les chaînes de caractères sont stockées au format « chaîne de caractère » au milieu du reste. Wow !ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 3.
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ? Pas pour des raisons de performances j'espère parce qu'on peut très bien avoir des performance en fichier texte.
Si je lui demande de le lire tout de même il voit des bouts de textes dedans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Ben ça dépend ton index il est en binaire ou pas ? S'il est en binaire pourquoi diantre l'est-il ?
Ok on va replacer les choses dans le contexte.
On me dit que l'on ne peut pas indexer ou rajouter des métas à un fichier sans placer le fichier lui même au format binaire (et donc non lisible humainement). Je répond que si on peut.
Maintenant effectivement l'index lui même n'a aucun intérêt à être lisible humainement. A partir de là le mettre au format texte serait un pur gaspillage de place. Ce qui ne change rien au fait que l'on peut avoir à la fois des gigas et des gigas de données au format texte ET un index et des métas très performantes sur ces données.
SQLite étant un mauvais exemple je vous présente mes excuses pour l'avoir utilisé - et je vous propose comme exemple de rechange un systèmes de fichiers qui contient des boites au format maildir et avec dans le role de l'indexeur/placeur de meta le serveur dovecot.
Vous avez des giga de données texte, un système d'index et de cache performant, un systême qui peut être accédé par plusieurs clients simultanément en lecture/écriture sans trop de soucis et qui tourne en prod de façon nickel chez suffisament de personnes pour que l'on ait du mal à dire qu'il s'agit d'un exemple ultra-spécifique que moi seul ait vu dans un monde imaginaire à venir.
Es-ce que ça vous va comme exemple pour comprendre ce que je veux dire ?
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 0.
Comme journald donc?
Le reste non plus : il y a des outils adaptés pour lire journald, comme des outils adaptés pour lire un fichier avec des caractères UTF-8.
Cool, 1 fichier par ligne de log, pour pouvoir "facilement s'y retrouver et indexer". Ou pas.
Et puis, pour pouvoir utiliser les performances, il faut un utilitaire différent, un peut comme journald donc.
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 6.
Placé dans un même fichier il t'empêche juste d'utiliser grep, sed et autres awk dont certains expliquent qu'ils sont vitaux pour leur survit ou ceux de leur entreprise. Oui grep fonctionne mais il n'est pas efficace car on se retrouve avec du bruit qui pourris toutes les sorties, etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 22 octobre 2012 à 09:09.
Effectivement, remettons dans son contexte :
- Actuellement, tes logs sont en format binaire de chez binaire (à moins que tu me dises que tu stockes sans compresser), un grep sur ton .gz va rien donner, il faut un utilitaire pour que ce soit lisible en texte (gunzip par exemple)
- avec journald, tes logs sont en format binaire de chez binaire, un grep ne marchera pas plus, il faut un utilitaire pour que ce soit lisible en texte
Désolé, j'ai du mal à voir la moindre différence, les deux sont lisibles avec grep après une petite manipulation. Juste des gains en plus pour journald (toutes les nouvelles fonctionnalités), rien d'enlevé.
Si tu gardes tes logs non compressés (seule manière d'avoir du texte!), ça doit calmer tes disque durs, ou alors c'est que tu n'as pas de serveur un peu chargé.
[^] # Re: Pourquoi du binaire
Posté par Marotte ⛧ . Évalué à 0.
On peut tout de même grepper vite fait :
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 7.
comme journald, youpi!
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 3.
Plus rapide : zgrep.
Mais pas sûr que ça fonctionne avec tous les formats d'archivages, en plus de gzip y'a déjà le bz2 et le XZ commence à se faire une place.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 3.
Tu veux dire : avec un truc qui lit du binaire pour mettre en texte? Kaane ne peut pas accepter ça, c'est un outil pas bien car pas grep ;-).
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
c'est un outil pas bien car pas grep
Je n'utilise jamais grep (ou sed ou awk) sur mes logs. (Enfin tellement rarement que c'est vraiment exceptionnel)
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 4.
Par curiosité, qu'utilises-tu ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
Par curiosité, qu'utilises-tu ?
Ca dépend des cas.
Pour le firewall, j'utilise les outils fournit avec (je suis sous pf que ce soit openbsd ou freebsd).
Pour les logs Apache et DNS vu qu'il y en a des tonnes, il y a d'abord un filtre baysien puis split des logs en deux (logs clasiques avec tout que je ne consulte quasiment jamais, logs de trucs "surprenant" qui ne fait souvent que quelques lignes par jour). Si j'ai un doute généralement j'ouvre le fichier de logs de l'heure concernée et j'y vais à la main (ca va vite vu que c'est classé par heure).
Pour les trucs verbeux et non prévisible (par exemple les echecs de mapreduce) c'est du custom basé sur Lucene
Pour les trucs proprios (on gère pas mal d'autocoms/gateway télécom non libres) on a des outils proprios pour analyser (et ils vont vite). de totue façon on a pas le format pour écrire nos propres trucs.
Sinon il y a aussi du awstats et des scripts qui font appel à rrdtool pour les rapports.
Après sinon il y a d'autres admins qui préfèrent lire les logs sous Mac ou sous Win et qui ont des outils à eux pour le faire.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Désolé, j'ai du mal à voir la moindre différence
C'est pas grave, tu t'en remettras.
[^] # Re: Pourquoi du binaire
Posté par fravashyo . Évalué à 2.
que ça soit un fichier texte ou un autre type de fichier, il faut toujours un utilitaire pour lire un fichier (par exemple less pour les fichiers textes).
Tu crois vraiment que les sysadmins s'amusent à utiliser gunzip pour décompresser les fichiers, puis lire ensuite les fichiers décompressés avec un visualiseur de texte ? Il y a zless et zgrep pour ça (éventuellement gunzip avec l'option -c).
De plus, dans les distributions lorsqu'elles compressent les fichiers log, c'est uniquement pour les vieux log, le dernier log est généralement en clair, pas compressé.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 8.
Ce sont donc bien des outils adapté à un format de stockage binaire, comme le sont les outils de journald.
Quand on cherche dans un log, ce n'est pas forcément dans le dernier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à -1.
Et tu sais quelle taille ca prend d'indexer plusieurs Go de fichiers texte? Pourquoi on irait perdre de l'espace disque stupidement comme ca…
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 2.
Tu peux aussi stocker ton index dans un autre fichier, c'est ce que les serveurs imap (genre dovecot ou cyrus) font déjà avec les fichiers mbox. Il faut juste détecter les modifications de ton fichier texte pour actualiser ton index quand c'est nécessaire.
C'est juste que sqlite est un exemple particulièrement mal choisi, tu aurais pu parler directement des mbox :p
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
C'est juste que sqlite est un exemple particulièrement mal choisi, tu aurais pu parler directement des mbox :p
Oui. Mauvais exemple. J'ai changé d'exemple. Mail Dir - Dovecot est un meilleur set pour se placer dans une situation similaire (nombreux fichiers, sous répertoires, "logueur" centralisé) et avec des performances assez bluffantes.
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 3.
Sauf que maildir est encore un format très différent, qui n'est pas comparable aux syslogs: une entité (un mail) par fichier, des méta-données encodées dans le nom du fichier sur le disque, et, de surcroît, une normalisation très forte et très complexe des opérations que l'on peut réaliser sur un dossier mbox.
Le format mbox, qui contient plein de messages dans le même fichier, est beaucoup plus similaire à la situation des syslogs: plein d'entités dans le même fichier et un nom qui n'a aucune signification particulière et sur lequel on fait (majoritairement) du append-only.
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 7.
Et journald c'est quoi ? C'est des données en texte, plus des trucs en binaire pour indexer ces données.
Après avoir écouté quelle est la difference entre le bon et le mauvais chasseur …
http://www.youtube.com/watch?v=vH2GdDrJpKg#t=2m59
voila maintenant quelle est la difference entre le bon et le mauvais format de données: Le bon format de données comme sqlite, il stocke ses données texte et les indexe avec du binaire. Rien à voir avec le mauvais comme journald, qui stocke ses données texte et indexe ca avec du binaire.
[^] # Re: Pourquoi du binaire
Posté par Obsidian . Évalué à 2.
Chiche ! :-)
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 2.
Ces idiots de chez sqlite ne connaissent rien de la puissances de grep, sed et awk ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 2.
Quelle bonne idée, je vais installer beagle sur un serveur!
[^] # Re: Pourquoi du binaire
Posté par groumly . Évalué à -7.
Tout de suite!
Ya vachement plus simple, qq boxes solr, un plugin a rsyslog pour renvoyer les logs dedans, et un front end a solr pour te permettre de faire des recherches.
Super simple a indexer le texte, on te dit!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du binaire
Posté par groumly . Évalué à -5.
T'en as de la chance! Certains ont des sites avec du vrai traffic cela dit, et pour eux, yen a un peu plus que ca.
Derniere fois que j'ai eu le privilege d'avoir accès au VM de prod pour faire un grep precis sans que splunk me pete a la gueule, me suis retrouve avec la bagatelle de 25-30Go (gzippe, of course) de logs. Une semaine de log, 8 VMs par box physique, 20 box physiques, forcemment, ca monte vite.
Le grep qui a suivi a bien prit 15-20 minutes a tourner. Et encore, j'avais la chance d'avoir un grep tres simple (URL path unique, pas de regex), ruby a prit le relais pour me sortir des chffres un peu plus detailles.
Et je tourne sur un SSD, hein, j'ose pas imaginer si j'avais un spinner.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pourquoi du binaire
Posté par Maclag . Évalué à 4.
Il y a effectivement toutes les commandes nécessaires pour parcourir et trouver rapidement ce qu'on cherche dans les logs. Je ne vois pas en quoi c'est de la mauvais foi que de le dire?!
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
Tu dis plus loin que tu as lu un article de Lennart où il explique les raisons, donc l'intérêt, tu le connais déjà.
Après si tu n'es pas d'accord, tu peux argumenter (un peu comme en-dessous, sauf que… voir plus bas!)
Chez moi, (Debian Sid, avec tous les réglages de log par défaut), le répertoire /var/log fait 416Mo.
Mais "chez moi c'est comme ça", c'est rarement un argument pertinent pour justifier ou invalider une décision technique sur le développement d'outils de production. Le répertoire ferait 300ko, je ne verrais toujours pas en quoi les logs binaires sont un problème, à défaut d'être un progrès.
Je ne comprends pas ce que tu veux dire par "on ne peut pas stocker des données binaires".
J'ai l'impression qu'on y arrive très bien au contraire:
-exécutables
-documents bureautique, fichiers pdf
etc.
En fait, tout ce qui n'est pas en texte clair peut être considéré comme étant en binaire, et la différence est uniquement pour nous, humains, la machine ne la voit pas. (ou alors faut m'expliquer en quoi l'anglais est plus compréhensible que du code "binaire" en Unix).
Même le format texte dépend d'un encodage, et on le décode avec les outils texte.
Donc vraiment, non, je ne vois pas.
S'il avait dit "format texte optimisé avec un nouvel encodage" et au lieu de catd, il avait un patch sur cat sans en parler, tu n'aurais peut-être même pas vu la différence…
Je pense qu'on attend avec impatience plus de détails…
[^] # Re: Pourquoi du binaire
Posté par YBoy360 (site web personnel) . Évalué à -2.
c'est dingue, on me dit que mysql n'utilise pas grep!
ils remettent en question la sacro-sainte et énigmatique philosophie de la drosophile à crotte de marsoin en chaleur, si belle par sa pureté resplendissante dans le noire : "si un truc peut faire un truc, alors elle peut tout faire le truc, même d'autres truc, puisque tout est fichier et Kiss" …
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 6.
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
a) Moins pratiques : il faut lire les logs sur un ordinateur qui a systemd et toute la clique installé. Si on essaye de lire les logs justement parceque le serveur plante/se comporte bizarrement il faut donc une autre machine avec systemd et toute la clique installée. A comparer avec des logs que ej peux lire sur n'importe quel machine ou presque et traiter avec le logiciel de mon choix.
b) Moins puissantes : avec des formats en texte pur je peux TOUT indexer si je veux, ou ne rien indexer si je veux aussi. Avec systemd si je veux utiliser les index en place je dois passer par l'API C, si je veux d'autres index tout le temps il faut soit que je passe par les USER_JOURNAL_FIELDS en les dénaturant soit que je fasse des exports et que je les indexe à la main (mais du coup je perd les index de base). Donc par exemple si je veux debugguer une phase initialisation SIP à la volée - ben je peux plus. Comme l'export ne fonctionne pas en continu ou en temps réel je suis obligé de faire un test, puis d'exporter, puis de lire le log et de recommencer. On dira ce qu'on voudra mais j'aimais tail -f moi.
c) Moins performant : Sur les choses qui sont prévus comme telle, il ne dervait pas y avori de soucis de performance avec journald. Il sera probablement plus rapide sur certains cas et moins rapide sur d'autres (Un format binaire normé peut difficilement battre de l'append de base sur de gros évènement genre crash java avec trois page de détails - par contre sur une flopée de petites insertion il devrait être meilleur.) Ceci étant j'attend une version stable pour faire des tests et voir le résultat.
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 1.
Non, il suffit de journalctl.
Tu peux toujours le faire en configurant journald pour qu'il envoie les logs à ton système d'indexation préféré.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Spack . Évalué à 3.
http://packages.debian.org/wheezy/amd64/systemd/filelist
Pour l'instant, les deux sont dans le même package. Donc
journald=systemd…[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 2.
rien n'empêche d'en faire un paquet à part (même si on ne peut nier qu'ils sont fort lier, ça n'en fait pas une raison valable), le paquet n'a rien à voir avec le logiciel
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 2.
Et alors ? Sur Debian que tu cites, tu peux installer systemd sans l'utiliser.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Spack . Évalué à 2. Dernière modification le 24 octobre 2012 à 11:17.
Question : Peut-on installer journald sans systemd ?
Réponse : Non, actuellement les deux sont dans le même paquet.
Après on peut refaire le monde mais là, en ce moment même, je ne peux pas avoir journald sans installer systemd avec. Cela dit, je ne suis pas contre leur séparation dans deux paquets distincts pour profiter de journald moins intrusif que systemd.
Dans une utilisation serveur, je me vois mal installer un paquet ne servant à rien par pur sécurité.
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 3.
Oui et alors ? J'ai pas dit le contraire.
Je ne parle pas non plus de l'installer sur un serveur. Relis le thread :
Donc tu peux lire les logs sans utiliser systemd, il suffit de l'installer sur une autre machine, pas besoin que ça soit un serveur.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 3.
Non, il suffit de journalctl.
Qui a besoin des libs (au sens large hein - sd-gateway et totu le toutim) de journal, qui ne peuvent pas fonctionner sans les libs de systemd, qui à leur tour requierent DBus et d'autres trucs etc. En gros systemd et toute sa clique quoi.
Tu peux toujours le faire en configurant journald pour qu'il envoie les logs à ton système d'indexation préféré.
Oui je peux mettre journald juste pour faire joli et continuer à travailler en vrai avec syslog et consors, le tout pour un overhead modique. Mais là je ne vois pas l'interet.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 3.
Ce qui est bien avec le libre… Ah non, en fait, rien à voir avec le libre! Ce qui est bien avec un format documenté, c'est que si le logiciel de lecture "par défaut" ne te convient pas, tu peux te cotiser et/ou développer un truc automne qui te plait à 100%.
Faut juste se dire que si ce n'est pas encore fait, c'est peut-être que dans la vraie réalité, ce n'est pas un problème.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Ce qui est bien avec le libre… Ah non, en fait, rien à voir avec le libre! Ce qui est bien avec un format documenté, c'est que si le logiciel de lecture "par défaut" ne te convient pas, tu peux te cotiser et/ou développer un truc automne qui te plait à 100%.
C'est clair je n'ay avais pas pensé. Je vais de ce pas développer
journalgrep, journalawk, journalsed, journaltail, journalvi, journalemacs, journalperl, journal…
Bien sur.
Ah et en plus il y a un petit truc tout léger dans la page freedesktop :
Or, to put this in other words: this low-level document is probably not what you want to use as base of your project. You want our C API instead! And if you really don't want the C API, then you want the Journal Export Format instead!
Tant pis pour journalless, journalmore, journaleclipse, journalcat, journal> …. Dommage, pour une fois que j'étais motivé.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 3.
journalctl et un pipe, et tu as tous les outils (c'est pals force des Unix? Je croyais… Bizarre, dès que ça arrange pas ses affaire, les bases Unix disparaissent). On ne parle pas de remplacer tous les outils, sauf ton imagination faute d'arguments qui tiennent la route.
On peux avoir des arguments objectifs? A moins que… Ah oui, pas d'argument objectif contre.
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 2. Dernière modification le 22 octobre 2012 à 18:18.
Donc en en revient au commentaire 4 crans plus haut : pour traiter les logs de Journald, il faut un Linux avec systemd.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 22 octobre 2012 à 18:22.
Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose). Pas d'imaginer de refaire toutes les commandes comme il l'a sous-entendu (impressionnant comme excuse quand on n'arrive plus à être logique avec soit-même), juste pour le plaisir de faire croire qu'il faut tout refaire alors que c'est assez simple en fait (mais déjà ce simple, personne n'a suffisamment souffert de systemd pour le coder…).
Faudrait suivre un minimum. Ou comment faire croire qu'il y a une difficulté la où il n'y a aucune difficulté. La résistance au changement fait dire pas mal de choses…
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 3.
Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose)
Et qui interprete les meta systemd, comme la date, le numero de PID, le nom de la machine etc. Bref un truc qui prend un fichier binaire raw et qui le formatte pour l'affichage, et bien entendu qui prend en paramètre les éléments qui m'interressent, sinon je remonte TOUT le journal à chaque fois, et qui jongle avec les différents formats de contenu pour que l'on puisse traiter les sorties simultanément (avec un cat par exemple) et qui possède un système pour faire du back and forth (non parceque des fois je vais vouloir revenir en arrière sur le fichier qui défile, par exemple depuis un more - toujours sans charger TOUT le journal en mémoire).
Contrairement à ce que tu as l'air de penser faire un système qui fonctionne avec tous les outils traditionnels unix dans un nombre satisfaisant de consoles est loin d'être évident. Il ne s'agit pas juste de cracher les logs ligne à ligne.
Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.
Je ne suis pas sur que ce soit beaucoup plus simple que de recoder les outils unix pour qu'ils attaquent le raw directement. (Moi en tout cas je me sens plus à l'aise à écrire journalcat et journalgrep qu'à faire journalFS).
alors que c'est assez simple en fait
Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer". Ils ajoutent aussi que si on ne veut vraiment pas utiliser l'API C il faut faire des exports complets (toujours via systemd). Mais alors attaquer les fichiers en raw - surtout pas mon bon ami.
La résistance au changement fait dire pas mal de choses…
Etre convaincu d'avoir raison et penser que toute personne qui vous contredit ne peut être qu'un réactionnaire mal avisé et stupide fait dire pas mal de conneries aussi.
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à -1.
En attendant, tu peux fournir des vrais arguments? Parce que la, ben… Non, il y a rien sauf de la résistance au changement, juste parce que la commande ne s'appelle pas pareil et ça chamboule les petites habitudes. Encore une fois, tu es libre de maintenir ce que les autres n'ont pas envie de maintenir car trop chiant.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 4.
En attendant, tu peux fournir des vrais arguments? Parce que la, ben… Non,
Dans l'ordre du thread
https://linuxfr.org/nodes/96086/comments/1401649 : réponse à gnumdk sur l'avantage du parsage des index. Bien entendu ca ne marche que pour les index prédéfinis par journald, pour tout le reste soit on indexe à la mano soit on est en O(n) comme journald.
https://linuxfr.org/nodes/96086/comments/1401342 : deuxième partie : comment faire confiance à un init aussi fragile sur des trucs aussi cruciaux que le montage de disques NFS et qui se vautre quand il y a un fichier à la racine du /var. Je veux bien que ce soit le "début" de systemd - mais malgré tout c'est assez surprenant un init qui explose en vol comme ça. Surtotu quand on voit que les corrections ne sont pas faites coté systemd - mais coté appli (pour pas faire de mal au pauvre init tout fragile…)
https://linuxfr.org/nodes/96086/comments/1401231 : On peut parfaitement indexer des fichiers textes (et même le faire bien) - ca ne saurait donc être une raison suffisante pour passer à un format binaire. Premier (mauvais) exemple avec sqlite, second meilleur exemple avec dovecot + maildir/mbox
https://linuxfr.org/nodes/96086/comments/1401645 : Explication sur pourquoi journald est moins pratique et moins puissant en l'état que syslog. Petite digression sur le fait qu'il faille rameuter tout systemd pour lire un fichier de log (ce qui est pénible). Deuxième digression sur le thème "T'a qu'à utiliser les outils classiques pour ça". Merci, je sais que les outils classiques fonctionnent. Le but étant de montrer des lacunes (ou non) de journald, citer le rappatriement des données au format texte et leur analyse par les outils classiques n'apporte pas grand chose.
Ca serait mal élevé de ne parler que de moi :
https://linuxfr.org/nodes/96086/comments/1401432 : Alors oui, je ne sais pas de combien journald réduit la chose, mais toute réduction de taille est la bienvenue. Y-a-t-il seulement réduction de taille, je ne suis pas convaincu. Moonz non plus apparament.
https://linuxfr.org/nodes/96086/comments/1401277 : Tu es bien gentil de fournir tant d'arguments (la, pour le fichier spec, c'est clair, net, précis…), moi il me suffit déjà de regarder qui paye le salaire du développeur pour savoir au moins pour une distrib! Je demande une position officielle, on me répond par un commentaire dans un fichier source. Tu as l'air de considérer que c'est la preuve ultime. Pas convaincu.
https://linuxfr.org/nodes/96086/comments/1401344 : Mais je découvre qu'il y en a qui s'y mettent alors que le produit n'est même pas en alpha. Ou alors c'est du bluff, juste pour troller et inventer des critiques quand il n'y en pas. Je m'interresse à un produit qui modifie profondément le fonctionnement du système et qui nécesite une planification avancée c'est donc que je cherche à troller. Il n'y a pas d'autres explications possibles.
https://linuxfr.org/nodes/96086/comments/1401239 : Mais alors, pourquoi personne ne l'a donc fait? Faut croire que ce n'est pas si facile… qui va bien avec :
https://linuxfr.org/nodes/96086/comments/1401705 : alors que c'est assez simple en fait (mais déjà ce simple, personne n'a suffisamment souffert de systemd pour le coder…). et avec :
https://linuxfr.org/nodes/96086/comments/1401688 : Faut juste se dire que si ce n'est pas encore fait, c'est peut-être que dans la vraie réalité, ce n'est pas un problème.
Si ca n'existe pas dans l'ancien système c'est que c'est très compliqué, si ca n'existe pas dans le nouveau système c'est qu'il n'y en a pas besoin.
https://linuxfr.org/nodes/96086/comments/1401374 : Comme journald donc? Oui comme journald, le truc étant de démontrer que l'on peut doner à un fichier texte le même type d'index qu'à un fichier binaire tel celui utilisé par journald, on se retrouve au final avec un index du même type que celui de journald.
https://linuxfr.org/nodes/96086/comments/1401695 : journalctl et un pipe, et tu as tous les outils La j'avoue que j'ai beaucoup rigolé - déjà parcequ'une fois de plus il s'agit d'un raisonnement de type "Tu vois bien que le nouveau système est mieux, vu que l'ancien fonctionne" et ensuite parceque non, journalctl et un pipe ca ne donne pas tous les outils loin de là. Et surtout ca ne donne pas le comportement habituel de navigation au sein des fichiers de log. Journalctl c'est pas vraiment gunzip - je peux pas franchement faire un cat de tous mes filtres journald et les piper dans un less.
https://linuxfr.org/nodes/96086/comments/1401731 : Libre à toi de ne pas prendre systemd et journald, mais il faut assumer le coût de maintenance de ce truc archaïque que tu veux à la place. On parle du truc archaïque que tu me conseilles d'utiliser toutes les trois lignes quand je t'expose un problème ? Oui je pense que je vais suivre tes conseils et le garder encore un peu. Au moins jusqu'à ce que systemd devienne capable de faire ce dont j'ai besoin professionnellement. Je suis plus BSDinit que sysvInit (mais c'est un système archaïque aussi) et on est un petit nombre à vouloir le garder ce système archaïque. (Tous des réactionnaires à ornière j'imagine)
https://linuxfr.org/nodes/96086/comments/1401734 : Un peu comme un log texte qui est différent suivant la distro? Les log, c'est presque la même chose partout… Mais tu les aime,s va comprendre pourquoi.
Je sais qu'on est pas supposé dissocier le fond de la forme, mais rassure moi, tu as conscience du fait que tu parles du contenu et moi du contenant ?
Voilà, voilà…
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à -2.
Mais qu'est ce que tu attends toi le génie de l'informatique pour aller apprendre à tous ces connards de dev comment faire leur travail ?
J'avais pas compris ton délire sur les indexes, c'est vraiment n'importe quoi… Les indexes journal, ils répondent à 99,9999999999999999999999999% des cas sauf le tiens…
Tu m'appelles le jour ou tu cherches dans tes logs sur un autre critère sur ceux fournit par journal… Après tu utilises grep pour faire du filtrage plus fin.
Donc on a O(log(n)) suivit de 0(n) sur le résultat précédent ce qui n'a rien à voir!
Bref, depuis le début, tu te branles la nouille et tu nous faire perdre du temps, va coder si t'es si bon que ca et que t'as tous compris aux problèmes d'init et de logs… Vivement de voir ton magnifique travail…
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 7.
Tu m'appelles le jour ou tu cherches dans tes logs sur un autre critère sur ceux fournit par journal…
J'ai pas les moyens financiers.
En partant du principe que l'index sur service ne compte pas vraiment (dans l'ancien système je serais allé chercher le bon fichier de log à la main mais ça ne pose pas vraiment de problème.)
Rien qu'aujourd'hui :
Problème avec une gateway SIP : donc parsage de log sur le contenu, notamment au niveau des tokens de sécurité dans les phases d'initialisation. Petit filtre sur l'init et sur l'adresse IP du client - damned c'est pas indexé par journald. (environ 15 coups de fil à vue de nez)
On continue avec la mise en place d'une nouvelle stratégie de cache - petit tests sur les expirations de cache du proxy et du memcached en fonction du log/delog des users. Petit filtre IP extérieur/login/réponse memcached - caramba encore raté (une petite vingtaine de coup de fil)
Les utilisateurs se plaignent d'un ralentissement. Ca serait les tests ? (Petit filtre sur les IP des machines des admins dans les logs des serveurs de prod - non c'est pas ça (3 coups de fils)) - par contre awstats montre une grosse monté des connexions, notamment en erreur. Ben tient tou vient de la même plage IP extérieure (5 coup de fils) qui nous casse aussi les pieds sur Bind (1 coup de fil), sur les ports mails (1 coup de fil), et même sur les plages CIFS (1 coup de fil). Ban de la plage et mail bien senti au provider (qui en a probablement rien à foutre mais c'est pas une raison pour ne pas le faire).
Donc aujourd'hui seulement entre 40 et 50 coup de fils comme ça, à la louche. Et encore tu t'en tire bien on a pas débugué de java ou de Riak aujourd'hui.
et tu nous faire perdre du temps
GNARARARARH Je vous oblige a répondre à mes posts sur linuxfr grace à mes grands pouvoirs. Je suis diabolique.
va coder si t'es si bon que ca et que t'as tous compris aux problèmes d'init et de logs
Tout à fait le fait d'avoir des problèmes qui ne sont pas résolus par systemd fait de moi
a) Un expert sur tout ce qui concerne l'init et les logs
b) Un développeur émérite
c) Un mec avec assez de temps libre pour recoder tout ça en mieux
Et le pire c'est que je suis fan de beaucoup d'idées de journald (la continuité des logs par exemple, le coté analyse temps réel qui viendra surement bientôt, les index - même si j'aimerai pouvoir définir les miens etc.) Mais journald a encore de grosses lacunes et un aspect rédhibitoire : celui de ne pas pouvoir fonctionner sans systemd.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 0.
Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client, damned c'est indexé par journald! Et même si ton serveur ne fork pas pour prendre en charge un nouveau client, tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 0.
Dans les faits c'est souvent inadapté :
Mais de toute façon, si on veut vérifier ce qu'il se passe, on veut souvent grepper sur l'adresse IP ou l'adresse mac pour plusieurs services à la fois.
Ceci dit la recherche peut souvent être réduite à un intervalle de temps plus ou moins réduit, et on peut toujours refaire un grep par dessus comme on fait avec les fichiers logs actuels.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 4.
Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client
Deux choses que je ne connais pas. Je connais l'adresse IP du mec qui me casse les pieds c'est tout.
tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Tout dépend de quoi on parle
- Si c'est service au sens de daemon - ben ca va être dur de pas filtrer dessus vu que généralement ses logs vont être à part. (genre /var/log/daemon) après si j'ai décidé de les fusionner avec d'autres logs ça devient un peu mon problème.
- Si c'est service au sens d'instance - la plupart des logiciels permettent quand mêle de loguer très correctement par instance, mais même dans le cas ou ils ne permettent pas (j'ai pas d'exemple en tête) - le facteur déterminant sera probablement ailleurs (une fois de plus IP extérieure, segment de protocole qui part en vrille, activité d'un utilisateur etc.) Donc on va passer d'une complexité de O(n) à une complexité de l'ordre de O(log(n)) + O(n*p) (Avec p < 1, p étant la proportion de logs dans l'instance concernée). C'est mieux, mais pas transcendant.
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
Une fois de plus je pense sincèrement que journald est meilleur que syslog, et sans systemd rattaché je serai déjà en train de le tester - mais c'est pas pour autant qu'il fait le café, ramène le journal et garanti le retour de l'être aimé. Il a des défauts - ben comme tous les programmes quoi.
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 5.
Les spec sont sorties vendredi. C'est tout de même intéressant de ne pas oublier le contenu du journal.
Non tu veux une position contractuelle sur un produit qui n'est pas encore en alpha.
C'est justement un problème des log texte. Tu n'a rien de fiable pour distinguer la forme et le contenu, tout simplement car l'ensemble des caractères servant à la forme peuvent être dans le contenu. Du coup tu as un parseur par serveur car chacun a son format ce qui te permet de savoir qu'au début tu as la date dans tel format suivi de tel caractère séparateur pour ensuite avoir tel donné etc. Là tu as une base qui permet d'avoir un début de standard (ça ne fait pas tout loin de là, mais on peut commencer à avoir une bibliothèque pour manipuler les log), ça aurais très bien pu être fais en xml par exemple, mais je n'ai pas l'impression que l'idée te plaise d'avantage :) .
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
Les spec sont sorties vendredi. C'est tout de même intéressant de ne pas oublier le contenu du journal.
Les specs commencent par "il ne faut pas lire les logs en raw". Ca va quand même être compliqué de créer un outil de parsing des données en stand alone et de l'incorporer au projet dans ces conditions.
Non tu veux une position contractuelle sur un produit qui n'est pas encore en alpha.
J'aimerai avoir une position contractuelle le plus vite possible. C'est pour ça que j'ai brulé un ticket pour poser la question. Maintenant je me doute bien qu'ils vont pas me répondre demain. Seulement quand j'entends dire que FORCEMENT les distribs serveurs vont passer à systemd, je me permet juste de signaler que les distribs en question elles ont pas l'air pressées de l'annoncer publiquement. Après mon interprétation est que ça ne sera pas si "forcément" que ça, ou pour être parfaitement exact je pense (opinion personnelle toussa) qu'elles cherchent à retarder au maximum le moment ou elles vont annoncer qu'elles ne supportent plus les autres init officiellement (ou alors avec des features en moins). Et si c'est le cas ca laisse à penser à son tour que tous les sysadmin du monde ne rêvent pas franchement la nuit du jour ou ils vont enfin passer systemd en prod. (Une fois de plus opinion personnelle toussa).
Après personnellement systemd me pose de vrais problèmes (que j'essaye d'exposer avec un succès mitigé), et je râle un peu quand on m'explique que journald est nettement mieux que tout ce qui existe dans tous les cas possibles et imaginables (sauf les miens - ce qui prouve bien que je trolle puisque journald est parfait)
C'est justement un problème des log texte. Tu n'a rien de fiable pour distinguer la forme et le contenu
A part les specs tu veux dire. J'avoue que c'est fouilli en effet. Mais bon le parseur universel qui fonctionne aussi bien avec les logs du serveur mail que le branchement des LUN SCSI que suivit de réplication LDAP j'y crois moyen.
Ceci étant si il n'y avait pas systemd derrière je serai probablement déjà en train de déployer journal sur les serveurs de tests - parce que oui il y a de vrais avantages et que les défauts ne sont pas insurmontables (mais ils sont là quand même).
_ ça aurais très bien pu être fais en xml par exemple, mais je n'ai pas l'impression que l'idée te plaise d'avantage_
Que les chose soient claires : je préfère des logs en binaires à du XML. En fait je préfère des logs en BIG5 avec maximum un caractère par ligne dans des fichiers de 2ko maximum à du XML.
Je ne vois pas comment faire rentrer du n'importe quoi (par essence un log on peut jamais être sur à 100% de ce qui va se trouver dedans) dans du XML à moins de faire de la soupe d'escape dans tous les sens. Et ça non merci.
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 2.
Ce n'est pas ce que j'ai dis. J'ai dis qu'on peut imaginer avoir des bibliothèques pour les manipuler. De la même manière qu'un driver de base de données (il ne connais pas tout les schemas de l'histoire mais il te simplifie la manipulation des données), une bibliothèque XML (il connait pas necessairement le XSD mais te permet d'aller taper dedans) ou les bibliothèques JSON etc.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 3.
Oui, par ce qu'il est bien connu que grep, sed, awk, perl et autres ont obligatoirement besoin d'un fichier, ils ne savent pas utiliser l'entrée standard qu'on leur donne avec un pipe.
Faux. Il suffit de libsystemd-id128.so et libsystemd-journal.so, pas besoin du reste de systemd. Sur ma machine ca prend environ 332ko.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Oui, par ce qu'il est bien connu que grep, sed, awk, perl et autres ont obligatoirement besoin d'un fichier, ils ne savent pas utiliser l'entrée standard qu'on leur donne avec un pipe.
Comment tu remontes dans les logs avant ton curseur initial avec une entrée standard ? Non juste pour savoir. C'est un truc qu'il m'arrive d'utiliser quand je lis des logs.
Ceci étant il semble que el bug soit en voie de correction :
http://www.spinics.net/lists/fedora-devel/msg172481.html
Faux. Il suffit de libsystemd-id128.so et libsystemd-journal.so, pas besoin du reste de systemd. Sur ma machine ca prend environ 332ko.
Alors vu que id128 ne sert qu'à générer des id et que -journal ne fait que de créer les interface j'ai du mal à y croire.
Si il n'y a pas un systemd qui tourne, journalctl n'est même pas capable de trouver les logs tout seul. Il va essayer de se connecter à DBus pour parler à systemd. Et si il n'y a pas, ben il s'arrête là.
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 3.
Je ne parle pas de journalctl, mais de l'API C qui permet de lire les fichiers. Exactement ce dont tu parlais dans le message auquel j'ai répondu, ou tu disais: "l'API C (qui nécessite bien sur d'avoir tout systemd installé)".
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
De ce que j'ai lu et compris (pas encore testé - pas sur de le faire très honnêtement) de ce qui est ici :
http://www.freedesktop.org/software/systemd/man/sd-journal.html
L'API fournit a la fois les capacités de parsing, mais aussi toutes les fonctionnalité pour faire client vis à vis de journald.
Si je me fie à ça :
#include
pkg-config --cflags --libs libsystemd-journal
Il doit être possible de compiler (et peut être même de linker) avec peu de libs installées.
Mais à l’exécution est-ce que ça peut vraiment se passer de tout le fratras qui est dans /src/shared ?
Ca serait une très bonne chose.
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 3.
Franchement, arrête de raconter n'importe quoi alors que tu n'as absolument jamais vérifier ce que tu avances depuis le début.
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 4.
journalctl -D /var/run/log/journal/|grep 3.6.2-1-ARCH
Le fait que tu indiques à la mimine à journalctl l'emplacement du fichier de log prouve effectivement de façon éclatante qu'il est capable de trouver les logs tout seul quand DBus est éteint.
J'imagine bien sur que pour le test soit concluant sur au moins un point tu as supprimé les différentes librairies systemd avant de lancer la commande.
Non parce que moi de mon coté j'ai juste relu les headers de journalctl et le makefile.am et très honnêtement j'ai toujours peine à croire que ca puisse fonctionner sans rameuter tout le fratras de libs et de dépendances qui vont bien.
Ceci étant je ne me suis pas penché à fond sur le truc, il y a peut-être moyen de limiter les dégats en allant modifier certains éléments de /src/shared - mais vache il y a du boulot.
Franchement, arrête de raconter n'importe quoi alors que tu n'as absolument jamais vérifier ce que tu avances depuis le début.
Et de 4 rien que sur ce thread là. Tu cherches à battre un record ? Ou tu penses sincèrement que ca sert à quelque chose ?
[^] # Re: Pourquoi du binaire
Posté par gnumdk (site web personnel) . Évalué à 2.
J'ai copié les données dans le path "volatile" alors que arch les attends dans /var/log/journal par défaut maintenant. Tu crois vraiment que journalctl a besoin de dbus pour ouvrir un fichier?
De plus ne vient pas me parler de dépendances et de libs systemd, je ne répondais pas à cela mais au fait que journalctl se vautre comme une merde si dbus et sytemd ne sont pas up…
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 4.
Ça te ferrais mal de créer des citations de manière classique avec markdown (qui s'inspire d'une RFC pour ça) avec des > en début de ligne ? Ça améliore la lisibilité :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 4.
Et avec grep ?
Tu peux tout à fait lire l'entièreté du log avec systemctl, ou lire ce qu'il s'est passé dans un intervalle précis. Il suffit alors d'agrandir l'intervalle.
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 6.
Je ne comprends pas très bien. L'intérêt dont tout ceux qui sont montés sur leur grand chevaux ici parlent c'est qu'unix c'est trop fort parce qu'avec du texte et des pipes ils ont des perf' de folie, qu'ils kiff le grep plus que leur femme et qu'awk rend le poil soyeux. Donc (avec un UUOC en prime)
Montre la puissance d'unix et des outils qui vont avec.
Donc si on part d'une commande catwoman qui dompte l'ignoble format de fichier binaire :
Qu'est ce qu'il faudrait dans cet outil ? Qu'il ouvre pas le fichier comme un goret, on est d'accord, mais pour le reste je ne vois pas ce qui révèle de cette commande. Par exemple tu parle de more (il y en a encore qui utilise more ?), qu'est ce qu'il lui faut pour qu'il puisse « back and forth » (ma recherche indique juste que c'est le quatrième DVD des foo figters) ? C'est une véritable question qu'est ce que la commande peut bien faire sur sa sortie standard pour cela ?
Comme quoi la simplicité KISS est illusoire ?
Donc le top serait de passer à Hurd qui lui permet de faire des trucs jolis pour ça :)
Encore une vraie question : en quoi fuse est une cochonnerie ? Il permet de pousser à l’extrême le concept du tout est fichier.
J'ai enlevé un seul mot et ça s'applique à 80 % des personnes qui ont posté sur cette page, moi compris (PAF !).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 5.
Le problème c'est qu'on ne vas pas faire catwoman fichier_au_format_immonde
On va faire catwoman --filtre filtre1 --filtre filtre2 --filtre filtre3 --répertoire répertoires_rempli_de_fafi --options_de_sorties option1 --options_de_sorties option2 | monanalyzer_que_j'aime
Le truc c'est que de taper tout ça c'est casse pied. Donc on va vouloir se créer des scripts qui simplifient la vie. Genre aller modifier monanalyzer_que_j'aime pour qu'il génère les filtres à la volée en fonction de demandes humaines compréhensibles, avec des options par défaut bien remplies etc.
Genre monanalyzer_que_j'aime --filtre filtre1 filtre2 filtre3 répertoire_rempli_de_fafi
Et bien entendu le résultat de la sortie peut contenir des éléments non imprimables du fait de corruption (ou tout simplement parce que les options que j'ai choisi peuvent afficher ce type de caractères) Et encore plus si je peux mettre un buffer de façon à ne pas déployer 3 000 000 de lignes en mémoire c'est mieux - mais si je peux utiliser les commandes (par exemple de less ou more) pour sauter de 500 lignes en avant ou en arrière sans devoir tout dérouler entre c'est le pied (c'est ça le back and forth - parfois nommé mode pager).
Si j'ai tout ça je peux vraiment bosser comme j'ai l'habitude. Mais c'est complexe à mettre en place.
Comme quoi la simplicité KISS est illusoire ?
Pour le dev oui (enfin jusqu'à Lennart qui a l'air bien décidé à venger des générations de dev du joug des sysadmins). Demande à Alan Cox pour voir - il a des trucs palpitants à raconter sur la console.
Encore une vraie question : en quoi fuse est une cochonnerie ? Il permet de pousser à l’extrême le concept du tout est fichier.
Tout est fichier OUI. Tout est système de fichier moins. Il y a quand même des trucs assez crade dans fuse (ce qui n'enlève rien au fait que c'est un outil très très pratique).
J'ai enlevé un seul mot et ça s'applique à 80 % des personnes qui ont posté sur cette page, moi compris (PAF !).
Merde, moi qui croyait être un réactionnaire hipster. Je pensais trop me la péter dans 2 ans genre "je crachais sur systemd avant que ce soit à la mode de le faire !"
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 2.
C'est certes plus simple que de tout réimplémenter, mais dans les faits, ce n'est pas parce que la lib est actuellement packagée dans systemd qu'elle ne peut pas être packagée séparément si un besoin est exprimé.
[^] # Re: Pourquoi du binaire
Posté par jyes . Évalué à 3.
Comme udev ? :-)
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 1.
Satisfaire ceux qui trouve un intérêt à systemd et ne pas faire son autiste qui fait chier le monde pour son plaisir.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 1.
Satisfaire ceux qui trouve un intérêt à systemd et ne pas faire son autiste qui fait chier le monde pour son plaisir.
Donc je rajoute un truc dont je n'ai pas besoin pour faire plaisir à des gens qui me considèrent comme un autiste parce que j'ose penser que systemd est un système inepte ?
Ecoute c'est l'argument qui m'a convaincu. Honnêtement dans ce thread on est déscendu très bas niveau mauvaise fois mais là on attend le top du top.
Donc vous pouvez me faire chier avec systemd mais j'ai pas le droit de vous faire chier avec systemd (parce que là je ferais mon autiste).
Ca me rapelle le bon vieux temps.
PLONK !
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 2.
Si tu ne veux pas de journald ne l'utilise pas alors. Après, ne pas plein pas non plus que les distribution l'intègre pour satisfaire un maximum de monde.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à -3.
L'avantage du libre est que si ça te plait pas, tu peux forker.
Problème : ceux contre systemd et journald ne savent faire que parler, personne ne se bouge le cul pour faire le boulot que d'autres ne veulent plus faire car il y a mieux aujourd’hui (Arch cherche du monde, par exemple)
Libre à toi de ne pas prendre systemd et journald, mais il faut assumer le coût de maintenance de ce truc archaïque que tu veux à la place, les autres ne sont pas tes esclaves, et les autres ont d'autres besoins (il ne sont plus au 20è siècle, l'informatique a évolué, les besoins ont évolué, la technologie a évolué)
C'est fou ça, déjà il y a les arguments contre les plus bidons (mais ce sont les autres qui sont de mauvaise foi!), mais ensuite les gens contre se plaignent de la liberté des développeurs…
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 2.
Et t'aimes pas journalctl -f qui fait exactement la meme chose ?
[^] # Re: Pourquoi du binaire
Posté par claudex . Évalué à 6.
Non, ça va à l'encontre de la tradition unixienne qui dit qu'il faut que la commande pour afficher la fin d'un fichier ne fasse ni plus, ni moins que quatre lettre et commence par t.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi du binaire
Posté par Kaane . Évalué à 2.
Et t'aimes pas journalctl -f qui fait exactement la meme chose ?
Tu veux dire journalctl -af -o verbose ? ou journalctl -f -o short ?
Le truc c'est que c'est "presque" la même chose. Avec soit des petits bouts en plus, soit des petits bouts en moins.
Si la ligne est trop longue journalctl -f la tronque, et puis certains metas donnés par systemd n'apparaissent pas.
Si je passe en -af -o verbose, j'ai la ligne entière et les métas mais je peux me rammasser des caractères à la con et corrompre ma console.
Donc effectivement on est pas très loin, mais pour de la production une fois de plus…
[^] # Re: Pourquoi du binaire
Posté par Zenitram (site web personnel) . Évalué à 0.
Un peu comme un log texte qui est différent suivant la distro? Les log, c'est presque la même chose partout… Mais tu les aime,s va comprendre pourquoi.
[^] # Re: Pourquoi du binaire
Posté par Anonyme . Évalué à 1.
Il suffit de faire :
Et voila, journalctl ne tronque plus les lignes, à moins qu'elles fassent plus de 50000 caracteres.
Et pour les metas donnés qui n'apparaissent pas, tu parles de quoi exactement ?
[^] # Re: Pourquoi du binaire
Posté par nud . Évalué à 5.
Je n'ai pas vraiment d'opinion sur journald, cependant:
Ben en fait, pour les besoins de la cause, tous les outils pour interagir avec les journaux ont une interface texte "machine-friendly".
Si l'esprit d'unix se résume à l'interface texte, il n'est pas question du stockage. En l'occurence, avec journald tu peux utiliser l'outil associé qui te retourne une suite de lignes de log, de la même façon que zgrep/zcat te permettent de retourner des lignes de log avec syslog, juste de façon plus rapide.
Et, soit dit en passant, l'argument du format texte robuste n'est plus vraiment recevable à partir du moment où il est compressé, ce qui est le plus souvent le cas pour les logs après rotation.
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 3.
Peut-être qu'il l'a compris mais qu'il considère justement que ce n'est plus en phase avec la réalité d'aujourd'hui.
Unix a cinquante ans, au bout d'un moment faut arrêter d'ériger le passé en sacro-sainte référence, faut voir un peu vers l'avenir aussi.
Je ne dis pas que tout est à jeter, loin de là, mais on peut tout de même remettre certains principes en question parce qu'ils ne sont plus adaptés, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par barmic . Évalué à 3.
Ou alors c'est toi. La règle indique que les programmes discutent entre eux via une interface texte, pas nécessairement que les données soient dans un format texte. Je ne connais pas les outils lié à journald, mais ce serait un viol de cette règle que s'il n'existe pas d'outils pour les retranscrire en texte sur une sortie standard. En fait la règles dont tu parle a pris de l'avance et accepte les fichiers binaires ça indique juste quand dans la mesure du possible les programmes doivent pouvoir travailler entre eux via une interface texte.
Il existe une commande zgrep pour traiter les log ainsi qu'un outil gunzip, mais où est donc l'intérêt ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi du binaire
Posté par zebra3 . Évalué à 8.
Quel standard ? Rien que sur l'encodage et la date, y'a rien de commun.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi du binaire
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
clair ! C'est quoi un format texte standard ? quel séparateur de ligne ? quel codage de caractère ? comment séparer efficacement différent champs en 'texte standard' en se restreignant à l'alphabet "texte standard", comment coder les nombres flottants, les dates, les listes, les sous-chaînes, comment identifier et nommer les champs…?
Bref, je nie pas non-plus l'avantage d'un log lisible d'un simple cat, mais il faut arrêter le mythe du texte standard, il n'y a pas de format texte standard.
Parfois l'argumentation du "texte standard" me fait penser à l'argumentation "pourquoi utiliser un protocole dédié sur un port dédié quand on peut faire ça sur du http" ! C'est un peu du même ordre…
ce commentaire est sous licence cc by 4 et précédentes
# Quel talent !
Posté par Christophe Merlet (site web personnel) . Évalué à -2.
Les logs binaires, je n'en ai pas rêvé, Lennart l'a fait !
Le plus beau, c'est de prétendre que c'est pour des raisons de performances, alors que pour les mêmes logs, les ordis d'aujourd'hui sont 1000 fois plus puissants que ceux d'hier !
Tiens, pour l'anecdote, sur un Dell, un driver déconne avec un message d'erreur abscons, le support technique semble au courant du problème. Faut réinstaller l'OS (en pensant a sauvegarder mes données). Bientôt sous systemd/Linux l'indébogable.
Ne pas comprendre que des logs en texte clair sont un minimum sur une install standard me fait halluciner.
[^] # Re: Quel talent !
Posté par claudex . Évalué à 6.
Du coup, il y a 10000 fois plus de client et donc bien plus de log. Surtout que les performances des disques n'ont pas suivi les processeurs.
Pour l'instant, ils le sont toujours, le nouveaux format n'est là qu'en parallèle pour accélérer les recherches.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quel talent !
Posté par zebra3 . Évalué à 2.
L'informatique ne se résume à un portable Dell avec un OS bureautique. systemd s'adresse aussi aux serveurs qui génèrent des millions de lignes de log (au hasard, les serveurs web).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Quel talent !
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 22 octobre 2012 à 15:20.
Et la machine fait 1000000 fois plus de choses qu'hier. Donc?
Pas compris le rapport entre l'anecdote et le format du journal. dans les deux cas, une simple commande fait le même boulot, rien de mieux, mais rien de pire.
Ce qui me fait halluciner est l'incapacité des gens à juste changer quelques lettres à taper pour voir des logs "texte".
[^] # Re: Quel talent !
Posté par gnumdk (site web personnel) . Évalué à 4.
Journal: O(log(n))
Grep sur fichier texte: O(n)
CQFD
[^] # Re: Quel talent !
Posté par barmic . Évalué à 2.
Parce que personne ne centralise ses logs entre plusieurs machines par exemple ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# POSIX
Posté par Spack . Évalué à 10.
En dehors du débat format binaire contre format texte (en fait si un peu quand même), je pense que le plus gros problème est que l'on perd l'usage des outils basiques définis par la norme POSIX.
Un des fondements d'Unix est l'usage d'interfaces textes pour plus d'universalité. Avec des logs binaires, sans
systemd, pas de logs. Alors oui, on sait que Lennart n'est pas un grand fan de POSIX et c'est peut être dépassé, mais actuellement, je peux lire mes fichiers logs quelque soit le système.Les logs sont quand même un élément central du système. Je dois pouvoir y accéder facilement en cas de problèmes sans avoir recours à des outils magiques. D'un autre côté, il est possible de demander à
systemdd'écrire comme avant dans des fichiers textes. Mais que se passe t-il en cas de bugs ou autres imprévus m'obligeant à avoir recours aux fichiers binaires ? Installersystemd? Utiliser un outils dédié ? Pas aussi simple dans un environnement de restauration le plus souvent minimal.[^] # Re: POSIX
Posté par Zenitram (site web personnel) . Évalué à -1.
Gni? C'est quoi qui empêche de faire un outil de traduction du formal (défini en plus!) vers ton joli fichier texte "compatible avec les idées POSIX"?
C'est un faux argument.
Aujourd’hui, tu y accèdes déjà par des outils magique (gunzip, grep…), tu ne fais que changer d'outil magique, mais bonus : tu peux du coup faire du texte lisible (parce que bon, faut être mage pour le moment pour réussir à lire les logs)
[^] # Re: POSIX
Posté par claudex . Évalué à 2.
Et il y a des outils pour exporter dans une interface texte (un équivalent à zcat avec les logs actuels), il y a donc bien moyen d'utiliser une interface texte, je ne vois pas la différence.
Les environnements de restauration que j'ai utilisé permettent d'accéder à /usr/bin où se trouve journalctl, je ne vois pas le problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: POSIX
Posté par gnumdk (site web personnel) . Évalué à 3.
Si tu as configuré systemd pour "forwarder" tes logs vers syslog, la question ne se pose même pas.
[^] # Re: POSIX
Posté par zebra3 . Évalué à 1.
Peux-tu me citer l'extrait de la norme POSIX qui spécifie le format des logs ? À part une RFC sur les messages envoyés à syslog, il n'y a rien, aucun format de stockage n'est défini.
Et si c'est si mal que ça, pourquoi est-ce que personne ne râle sur Rsyslog qui permet d'enregistrer ses logs dans une base de données depuis des années ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: POSIX
Posté par groumly . Évalué à -6.
Vous etes mignon avec vos concepts des annees 70, mais si ya bien un domaine ou le texte pur est tout simplement inutilisable, c'est bien les logs.
En 73, ca marchait peut etre, mais de nos jours un desktop a une tetrachiee de process qui trouvent tous pertinents de logger un max.
Ma Console sous macosx me sort qq milliers de lignes de logs desktop depuis hier apres midi, j'ai pas specialement envie de grepper par magie toutes les lignes qui peuvent correspondre a un process, et le filtrage rend la lecture "live" du log possible.
Sur un serveur, pareil, grepper 20Go de logs, ca me fait pas specialement bander.
Les logs ne sont clairement pas que du texte, les meta donnees sont critiques, on va pas juste savoir quoi, mais aussi qui quand ou et la myriade d'autres petits details qui viennent avec.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: POSIX
Posté par elionne . Évalué à 2.
Je suis d’accord, avoir des outils connus et utilisés de tous est un avantage indéniable pour un point critique comme l’init.
C’est comme en programmation et utiliser les socket BSD par exemple.
Mais je pense que c’est aussi une question de choix. Si certains préfèrent les log binaires pour tout un tas de raisons, bon pourquoi pas. Moi j’avoue que ça ne me plait pas trop. Je préfère avoir le contrôle, comprendre comment les choses fonctionnent. Peut-être que systemd ne change rien à tous ça, mais il y une couche supplémentaire. Alors peut être que je suis peureux mais ça me fait peur.
Parce que si je veux utiliser less, vim, emacs, tail -f ou n’importe quoi pour lire mes log, je peux choisir.
Visiblement systemd permet également de faire des log en texte, bon très bien. Mais si j’ai pas envie d’utiliser systemd, la c’est plus difficile.
# Vivement journald sur tous mes serveurs!
Posté par krumtrash . Évalué à 0.
http://0pointer.de/blog/projects/journalctl.html
Ça tue sa maman!!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.