gnumdk a écrit 7492 commentaires

On parle d'un systeme d'init là, pas d'un gros soft.

Et ?

[gnumdk@tina ~]$ wc -l /etc/rc.sysinit 
980 /etc/rc.sysinit

C'est vrai que c'était tellement mieux ces scripts shell à rallonge…

Mais si tu as un début de réponse je veux bien que tu m'expliques.

Ben, si les distribs passent à systemd, c'est pour ne plus avoir à se prendre la tête avec cela dans l'avenir… Après, je pense pas que sysvinit va disparaître de ArchLinux par exemple, il sera dans Community au mieux, dans Aur au pire…

Il y'aura juste un paquet sysvinit-rcs avec tous les scripts de la distrib à l'arrache comme c'était le cas pour systemd avant que Arch commence la migration.

Bon bien sur, c'est dans le cas ou y'a vraiment des gens que ca motive de le maintenir.

Pour la prochaine version du journal, il sera possible d’empêcher l'altération des logs, en gros, un attaquant pourra supprimer tous les logs (et donc être grillé) mais pas les modifier.

"Un programme fait une chose unique et le fait bien"

Wai, enfin ca fait des années que cet argument est faux, tu veux une listes de programmes Unix qui ne respecte pas ce principe ?

Dans les gros softs, il faudrait plutot chercher les logiciels qui le respecte encore, genre postfix…

Un programme fait une chose unique et le fait bien, c'était surtout pour les utilitaires de la ligne de commande que ca avait un sens: "Ne cherche pas à tout faire dans un seul programme quand tu peux faire discuter ces derniers via des |"

Je suis pas sur que ce soit très pertinent pour un system d'init.

syslog, c'est un standard et journald ne peut pas arrivé et dire je ne sais pas causer avec syslog… Même le gestionnaire d’évènement de Microsoft sait le faire!

Sauf qu'il me semble que les logiciels formatent leur logs actuellement comme ils le veulent donc ca doit être un beau bordel à convertir si il faut gérer plein d’exceptions.

on a désormais les inconvénients de Windows

Et pourquoi c'est un inconvénient ? Et me dit pas qu'on peut pas parser facilement les logs, y'a les commandes qui vont bien sous Windows pour le faire, bon ca crache que du xml par contre…

Le problème des logs sous Windows, ce n'est pas vraiment l'outil mais les logs en eux même…

Si tu veux commencer à avoir des logs utiles, il faut activer des clés de registre et ouvrir des fichiers texte de 30000 lignes absolument imbitables. Le juste milieu chez Microsoft, on connait pas.

[m - 30] avant une réaction de PBPG :)

Ça c'est de l'argument! Tu ne peux pas faire plus clair parce que là je ne vois pas..

Arrête, Linuxfr c'est le repère des gens qui savent mieux que les devs de projets upstream comment architecturer un logiciel et qui sont tellement fort qu'ils préfèrent garder leur science pour eux plutôt que de contribuer.

J'aurai tendance à dire pour la même raison que MySQL ne stocke pas ses bases dans des fichiers texte gzippés ? :)

Non, en fait surtout parce que :

[gnumdk@arch 6bfe1c940a35530556670757000002d6]$ journalctl -o json /usr/sbin/sshd
Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 13:10:38 +0200.
[
{
        "__CURSOR" : "s=fb5ad03a60b34383af26f8a26268152c;i=2d5;b=9ee81871088f4474b32141ba6e2cb993;m=7ee67f;t=4c9
        "__REALTIME_TIMESTAMP" : "1346914845081883",
        "__MONOTONIC_TIMESTAMP" : "8316543",
        "_BOOT_ID" : "9ee81871088f4474b32141ba6e2cb993",
        "_TRANSPORT" : "syslog",
        "PRIORITY" : "6",
        "SYSLOG_FACILITY" : "4",
        "SYSLOG_IDENTIFIER" : "sshd",
        "SYSLOG_PID" : "348",
        "MESSAGE" : "Server listening on 0.0.0.0 port 22.",
        "_PID" : "348",
        "_UID" : "0",
        "_GID" : "0",
        "_COMM" : "sshd",
        "_EXE" : "/usr/sbin/sshd",
        "_CMDLINE" : "/usr/sbin/sshd -D",
        "_SYSTEMD_CGROUP" : "/system/sshd.service",
        "_SYSTEMD_UNIT" : "sshd.service",
        "_SOURCE_REALTIME_TIMESTAMP" : "1346914845081595",
        "_MACHINE_ID" : "6bfe1c940a35530556670757000002d6",
        "_HOSTNAME" : "arch"
}
]

En fait, journalctl permet de lire ses logs dans plusieurs formats ce qui peux vraiment facilité les choses quand on veut "parser" ces derniers. Et que c'est plus simple d'avoir des objets avec toutes les informations plutôt que des lignes de texte. Sur des très gros logs, journalctl doit être beaucoup plus rapide (affirmation gratuite).

Ca s'appelle le mode peer-to-peer en créant via dbus des DirectConnections.

Ah ben on y vient, c'est c'est comme cela que systemd fonctionne mais cela n'a absolument rien à voir avec dbus-daemon!

«Handles a peer to peer connection between two applications withou a bus daemon.»

Et donc du coup, ton premier argument:
>si dbus ne se lance pas la machine n'a plus d'init

était un gros mensonge, histoire de faire peur à tout le monde, c'est bien, tu viens de t'auto fusiller…

Ou alors, tu voulais dire que Lennart n'aurait pas du utiliser libdbus et recoder un système d'IPC à la main ? SUPER!

Et vient pas me dire que libdbus peut faire segfaulter systemd, parce que cette argument fonctionne aussi avec dash qui peut segfaulter pour une raison x ou y…

Je suis relativement convaincu que systemd gère cela depuis le début.

En regardant le code rapidement, il semble qu'il utilise libdbus pour communiquer en interne sur un socket: /var/run/systemd/private et c'est pour cela qu'il demande à dbus-daemon quand il le lance d'utiliser le même socket.

Après, je peux me tromper sur cette analyse à l'arrache du code…

Mais le service dbus-daemon n'a aucun influence sur le fonctionnement de systemd et systemctl.

Les non informaticiens qui vont être perdu sous Linux parce qu'ils ne peuvent plus comprendre le fonctionnement de l'init de leur OS (ce qui de plus est faut)… AH AH AH!

C'est pas systemctl -> systemd - C'est obligatoirement systemctl -> dbus-daemon -> systemd

Non.

Tiens donc, et ça fonctionne comment ? Je sens qu'on va rire…

Oui les sockets ont déjà été ouverte par DBus et donc systemsctl peut dialoguer avec
systemd.

Hein ? Tu sais comment fonctionne dbus.

C'est pas systemctl -> systemd

C'est obligatoirement systemctl -> dbus-daemon -> systemd donc si dbus ne tourne pas, rien ne tourne… Ce qui n'est pas le cas…

Je viens de faire un:
mv /usr/bin/dbus-daemon /root

Je reboot et magie systemctl fonctionne toujours…

Moi ce que je comprend du document de Lennart, c'est que systemd utilise dbus pour mieux controller les processus, en gros, il utilise un service dbus pour savoir quel process il a forké…

Mais cette fonctionnalité n'est valable que pour les process démarré après dbus…

POur les autres, il utilise, attention au magie, un fichier service.pid dans /run comme le faisait sysvinit dans /var/run.

Mais je ne pense pas dans l'exemple de abrt que ce soit systemd qui crée com.redhat.abrt, il s'en sert c'est tout.

Donc en gros, il utilise dbus pour controller des process linké à libdbus, donc si dbus est planté avec sysvinit on avait un démon lancé alors que ce dont il a besoin ne fonctionne pas, avec systemd un process non lancé parce que ce dont il a besoin n'a pas réussi à se lancer.

J'aimerai donc savoir ou est le problème, car je ne le comprend pas.

CF mon autre post dans l'autre thread pour cette question, systemd est aveugle et sourd
sans DBus. (ce qui ne l'empêche pas de lancer des services d'accord, mais pour le contrôle
on repassera)

Ce qui est faux, comme je te le démontre dans l'autre journal, il fonctionne très bien sans dbus.

Sans DBus systemd est sourd. (Et systemctl ne marche plus)

J'avais encore un doute sur le fait que tu ais raison…

Sauf que j'ai testé hier:
- systemctl stop dbus.service
- systemctl stop dbus.socket

dbus est alors coupé

• systemctl stop kdm.service

et oh, ca fonctionne et dbus est tjs coupé.

La seule bonne façon d'utiliser systemd c'est d'avoir des démons et des outils de controle
(type apachectl) qui parlent courament le DBus.

Faux, surtout que apachectl, c'est l'exemple type de l'outils codé parce que sysvinit ne répondait pas aux besoins… T'inquiètes, si systemd devient vraiment le standard, ton apachectl, il va partir dans /dev/null

Et je le redis: systemd n'a pas besoin de dbus pour fonctionner et pour controller les services

Pourquoi ne ferait-il pas un log rotate tout seul comme un grand ? Genre sur 2-3 sessions.
Parce que en cas de crash sur une session, c’est trop cool de pas savoir ce qui est arrivé ;-)

Ben a ce moment là tu crée le dossier… Enfin c'est sous Arch hein, j'imagine que sous Fedora, le dossier /var/log/systemd existe par défaut.

systemd ne dialogue vraiment qu'avec dbus

Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…

Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.

Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée. Mais c'est un plus par rapport à sysvinit donc paye ta critique…

systemd n'est pas compatible avec autre chose que Linux

Comme udev

De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer
le moindre démon.

On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
" In addition, systemd adds dependencies of type Wants to this target unit for those mounts listed in /etc/fstab that have the auto and comment=systemd.mount mount options set."

ils n'auront probablement jamais de support DBus.

Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…

et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs

Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!

Un peu comme si, tu insérais la lecture du jpeg dans le noyau parce que c’est trop cool

Moi, à ta place, j'aurai dit LibreOffice dans le noyau, plus c'est gros, plus ca passe…

Sinon, tu crois vraiment qu'on peut pas insérer une clé USB à chaud sans udev ?

À commencer par systemd qui met les logs ailleurs que dans /var si j’ai bien compris.

Non, t'as rien compris, il les mets dans un tmpfs tant que tu n'a pas créer /var/log/systemd…

Ce qui est logique, sur un desktop, j'ai pas besoin de logrotate et compagnie, les logs de la session en cours me sont largement suffisant.

Il est reproché à Dbus d'être un démon inutile sur LFS.

Comme je le dis plus haut, j'aimerai bien savoir en quoi udev est un démon utile pour LFS, ca me trou vraiment le cul! Genre, Linux From Scratch, ca veut pas dire se taper les mknod à la main quand on rajoute un niveau périph?

Pff, les distribs pour barbu, c'est plus ce que c'était…

En même temps, si le but de LFS c'est d'avoir un Linux aux petits oignons sans outils neuneu proof, je vois pas pourquoi ils veulent udev qui a quand même été la première brique vers tout ce qui a suivi… (pour avoir un linux qui fait tout à ta place).