gnumdk a écrit 7486 commentaires

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).

Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !

Mon dieu!!! Y'a deux dépendances vers une pauvre librairie, c'est la fin du monde, t'as raison, recompile tout! A ta place, je passerai sous Gentoo histoire d'optimiser un peu tout cela, ca se trouve, tu pourrais virer directement le support cups de samba, puis virer le support usb de cups, …

Et en plus, dans le cas de Arch, les paquets étant peu découpé, le service est installé mais je ne pense pas qu'il se lance tout seul.

Pfff, ca devient insupportable les mecs qui parlent de systemd sans savoir de quoi ils parlent…

Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit…

Mais bon, c'est tellement plus simple d'utiliser la bonne vielle technique du Fear, uncertainty and doubt.

Ou alors systemd répond à un besoin que sysvinit n'est pas capable de comblé…

Parce que bon, tu oublies quand même ArchLinux dans l'histoire, et tu le fais exprès en plus pour appuyer ton propos.

autant de goto

Comme dans le noyau Linux

de dizaine de return par fonction

Comme dans le noyau Linux

de pointeurs non-initialisés à NULL

Mwai, ca ce discute, mais bon, quand tu fais:

Manager *m;

assert(_m);
assert(running_as >= 0);
assert(running_as < _MANAGER_RUNNING_AS_MAX);

if (!(m = new0(Manager, 1)))
                return -ENOMEM;

Ca n'a absolument aucun intérêt de l'initialisé à 0 quand tu fais l'init 3 lignes plus bas…

Mais bon, après, tout ce que tu dis, c'est ce qu'on m'a appris à l'école mais c'est un peu la guerre de clocher entre les devs system et les devs objets.

Je n’ai pas trouvé de documentation qui me soit accessible.

https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files

Je précise que c'est une techno linux only qui n'est pas obligatoire pour démarrer comme dbus… Pourtant systemd dépend aussi de udev et cela n'a pas l'air de gener ;)