Etienne Bagnoud a écrit 1852 commentaires

Avant de proposer une optimisation, lire la page de manuel n'est pas du luxe :

[…]when snprintf() is called with size=0 then SUSv2 stipulates an unspecified
return value less than 1, while C99 allows str to be NULL in this case, and
gives the return value (as always) as the number of characters that would
have been written in case the output string has been large enough.

Donc 2 spécifications se contredisent sur cette fonction. Autant ne pas faire cette optimisation. De plus dans ton optimisation, tu appelles toujours deux fois snprintf et une fois malloc, alors qu'avec une valeur de départ bien choisie, tu peux être dans le cas où tu appelles le plus souvent une fois snprintf et une fois malloc et uniquement dans les cas spéciaux (voir jamais) appeler deux fois snprintf.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Le OOM killer se tune par sysctl (overcommit_memory knobs) et /proc (oom_adj), pas à la compilation.

Dans les noyaux 2.4 on pouvait ne pas le compiler, dans les versions suivantes je ne sais pas.

Tu sous-estime la complexité.
OK, tu testes ton pointeur, tu vois qu'il est NULL.
Mais pour faire les choses proprement, par exemple prévenir l'utilisateur, ou sauvegarder le fichier, et bien il faut de la mémoire.

C'est pour ça que tu vas allouer de la mémoire au lancement du programme pour avoir une "réserve" pour ce genre de cas. Si tu ne peux pas allouer un peu de mémoire, tu pioches dans ta réserve de secours pour gérer correctement l'erreur. Je ne sous-estime pas la complexité, je la reconnais mais la complexité n'est pas une excuse pour ne rien faire.

Mais ce genre de chose est complexe, et ce n'est probablement pas la peine de le faire sur un programme qui se content de te donner ta consommation en CPU/RAM/bande passante. Il n'a pas d'état, pas d'effets de bords, il peut crasher n'importe quand.

Tu en sais quoi qu'il pourrait crasher n'importe quoi ? Est-il utilisé dans un environnement plus complexe où un crash pourrait avoir des répercussion plus importantes ? Tu n'en sais rien, l'utilisateur part du principe que les programmeurs sont civilisés et qu'il peut utiliser le programme comme bon lui semble, y compris l'utiliser comme élément critique. Ou alors le programme indique clairement : "attention ce programme ne gère pas du tout la mémoire, il ne faut donc pas l'utiliser à part si vous n'en avez pas besoin" !

Par contre, mettre un assert() est pas mal pour éviter une éventuelle faille de sécurité due au déréférencement d'un pointeur NULL.

Sauf que ton assert est viré lors de la compilation en mode production. Donc utiliser un assert pour des questions de sécurité … je trouve ça bizarre. Mais on va me dire que toutes les possibilités existantes sont testées donc on peut utiliser un assert, c'est ça ?

Soyons sérieux, tu gueules si un appareil électrique grille à la première surtension. Pourtant il est prévu pour le réseau standard, donc pourquoi mettre un fusible ? Et finalement, c'est juste un gadget, pas un appareil critique, ce n'est pas grave s'il grille : il suffit de le ramener sous garantie. Sauf que ta maison à cramer à cause de ce raisonnement.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Il n'y a pas de finesse dans la gestion de mémoire. Soit on en fait, soit on en fait pas. Ne pas en faire c'est du mauvais travail : c'est ce genre de programme qui plante quand on fait un aperçu avant impression et qui nous font jurer et traiter le programmeur de tous les noms qui nous passent par la tête.

Et tu ne peux rien admettre sur l'état de la machine en te basant sur le retour d'un malloc de 3 octets. La seule chose qu'on peut juger, c'est la qualité du travail du programmeur : bonne ou mauvaise.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Et sinon, conky est compilé avec un compilo C

Il y'a des bouts de vrai C++ (template C++), donc il doit être compiler avec un compilateur C++.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Comme c'est fait là, si la ré-allocation échoue, on a plus de pointeur vers la mémoire allouée avant la ré-allocation donc on ne peut plus libérer la mémoire donc on a une fuite mémoire.

Je veux dire, ce genre d'erreur est très commune, surtout dans ce genre de cas (logiciel non critique, et si la taille des donnée à allouer est très petite, peu de chance que ça foire), donc ne t'offusque pas chaque fois que tu en vois une ;)

C'est une erreur très commune, c'est pour ça que j'en fais un journal. Que le logiciel ne soit pas "critique" ou que les données soient "petites" ne constitue pas une excuse pour coder n'importe comment.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui c'est ce qui est fait et si c'est NULL, on a un bloc mémoire avec plus un seul pointeur pointant dessus pour le libérer. Et donc on a une fuite de mémoire ! Et si on utilise un ordinateur portable qui ne redémarre jamais (entrer/sortir de veille) et bien la fuite peut prendre des proportions énormes !

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ceux qui veulent Packet Filter ou ZFS et préfèrent la gestion des paquets Debian au système de port de FreeBSD. Je n'aime pas le système de port de FreeBSD et j'utilise FreeBSD, Debian GNU/kFreeBSD est la réponse (bien que je n'ai pas encore passé mes FreeBSD à Debian GNU/kFreeBSD, c'est dans mes projets).

De plus l'équivalent à ZFS sous Linux est BTRFS, mais il n'est pas encore en version stable.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

C'est Lennart : il créé des problèmatiques puis trouvent des solutions à ces problématiques ; solutions qui créent de nouvelles problématiques inutiles. Ça permet aux "fans" de sortir la phrase qui tue : "ben si t'es pas content de systemd/journald/…, arrête de geindre et amène TA solution". Et essayer d'expliquer que le problème solutionner par Lennart est un problème créé par lui pour être solutionné c'est impossible.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Et moi qui croyait que c'était pour avoir un système de log aussi utile que celui de Windows … Mince !

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Lennart explique ses choix et les "révolutions" apportées par journald : https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

journald enregistre les logs dans des fichiers binaires, comme sous Windows. Donc les outils traditionnels ne sont plus utilisables.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Tu travailles dans une MJC, c'est ça ?

C'est quoi ça ?

De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.

Ou plutôt je surveille que les services critiques nécessitant un redémarrage immédiat avec un outil qui ne fait que ça et qui le fait bien.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

les serveurs n'ont pas besoin de systemd

C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…

Non, pas sans savoir pourquoi et comme le service est redondant, il n'y a pas de problèmes pour les utilisateurs.
Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer (ne serait-ce que pour m'assurer qu'il ne va pas se comporter sauvagement quand il est redémarré).

T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?

Les utilisateurs Apple parce que la veille disque et RAM fonctionne à merveille. Moi parce que j'ai passé deux heures à bidouiller mon système pour que ça fonctionne presque à merveille.
Et pour les utilisateurs Windows, de plus en plus.

Par contre, les utilisateurs Linux sont toujours à éteindre/allumer leur machine parce que s'ils mettent en veille, et bien c'est plus long : le réveil met du temps avant de planter et devoir, finalement, redémarrer brutalement la machine.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je ne dis pas que c'est la meilleure ou la moins bonne, je dis que ça pourrait être la meilleure solution. Qui sait, dans une infinité d'années, l'humanité, après avoir expérimenté, testé, mesuré une infinité de solutions pour le démarrage pourrait juger que l'init sys v, dans l'absolu, est la meilleure solution.

Là seule chose que je sais, c'est que systemd est un code n'ayant que deux ans et quand je vois, dans le code, autant de goto, de dizaine de return par fonction et de pointeurs non-initialisés à NULL, je me dis que systemd n'est pas prêt pour être en production.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Donc maintenant, si quelqu'un d'autre que Lennart propose des réponses [ … ]

Et s'il n'y avait pas de questions ? Et si la raison d'être opposé à systemd est que le init traditionnel est la meilleure réponse à la problématique du démarrage ?

L'init sys V apporte toutes les réponses nécessaire à la majorité des cas, systemd est une optimisation pour un nombre de cas restraints : les serveurs n'ont pas besoin de systemd (les quelques secondes de gagnées ne valent pas la simplicité de corriger le démarrage s'il y a un problème), les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent une fois chaque mois), donc pas besoin de systemd.

Demander des changements aussi profonds aux systèmes pour un concept presque révolu, le démarrage, c'est la mauvaise réponse aux questions : comment améliorer la veille prolongée et comment faire que l'ordinateur passe par la séquence de démarrage que lors de la première utilisation ?

On ne doit pas améliorer le démarrage, on doit fournir :

• Mise à jour du noyau à chaud
• Support veille en RAM et veille sur disque fonctionnel (et synchro, lors de la veille en RAM, la veille sur disque doit être faite afin de prévenir en cas de perte d'alimentation)
• Vérification, réduction et agrandissement du système de fichier en ligne
• Ajout et suppression de composant matériel à chaud (y compris processeur et RAM)
• Migration d'un système automatique depuis un disque vers un autre

Si on arrive à ça, l'informatique aura avancé de manière très significative. Et on s'y approche, mon ordinateur de tous les jours démarrent une fois chaque deux mois mais c'est pas encore parfait.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Bien vu, j'ai quitté Gentoo il y'a des années de ça et je ne reviens que très peu sur sa documentation.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

La ligne du contestable me semble vite franchie O.o
À me demander si je ne viens pas de la franchir …

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

En relisant ma réponse je trouve pas très clair mon "non" : non, ça ne va pas redémarrer ton Xmonad/Gnome/KDE/Xfce/… Tu ne vas même pas t'apercevoir que quelque chose se passe (à se demander si ça se passe).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui, cette méthode n'empêche rien. Mais il faut quand même les enlever des services démarrés au démarrage. Là on a surtout un mode "full power" qui va bien pour quand le netbook est sur le secteur.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Pas vu, pas pris ! Oui, c'est une erreur de ma part.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Parce que je n'ai jamais dis que ça ne le faisait pas, j'ai même dis que ça le faisait :

Donc ça le fait [ … ]

Ensuite j'ai précisé :

• Que ce n'est pas le but premier
• Qu'il y avait besoin de 2 fichiers de configurations au lieu de 1 pour le même effet
• Que le créateur de systemd dit que ça le fait, mais pas toutes les options possibles avec inetd

De ce fait je sentais pas nécessaire de citer une phrase qui appuyait ton propos alors que je l'appuyais moi-même (mais en plus nuancé).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Non. Par contre certaines distributions n'ont pas les mêmes niveaux d'exécution, il faut bien regarder la documentation de ta distribution. Là, l'exemple est pour Debian et il n'y a rien d'autre à faire que la ligne donnée en mettant le nom du service.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

One of the core feature of systemd (and Apple's launchd for the matter) is socket activation, a scheme pioneered by inetd, however back then with a different focus. Systemd-style socket activation focusses on local sockets (AF_UNIX), not so much Internet sockets (AF_INET), even though both are supported. And more importantly even, socket activation in systemd is not primarily about the on-demand aspect that was key in inetd, […]

Donc ça le fait, mais c'est pas l'objectif, c'est plus un effet de bord.

Et ensuite pour configurer à la "inetd", systemd nécessite deux fichiers de configurations au lieu de un afin de simplifier le tout !?!

You may wonder why in systemd configuration of an inetd service requires two unit files instead of one. The reason for this is that to simplify things we want to make sure that the relation between live units and unit files is obvious, […]

Mais pas de soucis, je suis sur un projet qui va simplifier encore plus, il faudra 3 fichiers de configurations dans une syntaxe inspirée de brainfuck.

Systemd est encore très loin de remplacer inetd, même Lennart le dit (à la fin du document que tu as mis en lien).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui et non, inetd n'est utilisable que pour les services réseaux et pas tous. MySQL, par exemple, ne semble pas pouvoir être démarré depuis inetd.

Et inetd, c'est un service en plus qui ne sert qu'à griller des cycles processeurs, à part 5 minutes par mois.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ça se fait déjà, ça s'appelle Mars 500 et ça consiste à enfermer six bonshommes dans un baraquement pendant quatre mois et voir si ça se passe bien ou c'est en train de virer à Half Life.

Pas besoin, depuis le temps que Secret Story existe (et là ils ont eu la bonne idée de mettre des hommes ET des femmes).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell