Anthony Jaguenaud a écrit 1956 commentaires

Oups, j’ai fait ça vite. J’ai copier/coller la barre d’adresse de firefox. Mais je n’ai pas revérifié sur le journal.

Merci pour la correction.

Ok, des sémaphores, on faisait ça en IUT

Très bien, puisque tu maîtrises le sujet, ce journal ne t’est pas destiné.

Tu as raison. Je n’ai pas bien expliqué pourquoi je fais ce post.

Ça fait quelques temps que je voulais écrire un petit journal sur les sémaphores, pour plusieurs raisons. 90% si ce n’est plus de l’usage d’un sémaphore se fait via des mutex, qui ne sont qu’un cas particulier. J’ai l’impression que certains confondent sémaphore et mutex. Donc je voulais faire un post dessus.
Il y a un mois à peu près, quelqu’un a proposé une implémentation de fifo. Ça m’a donné l’idée de faire un journal en utilisant les ipc standard en utilisant un sémaphore comme compteur de place disponible. Mais le temps m’a manqué. Suite à la discussion sur le démarrage des démons, je me suis dis, que c’était un bon exemple de sémaphore non mutex.
Mon journal est peut-être un peu rapide, mais le code est disponible, et est, je crois un bon exemple assez compréhensible. Je ne voulais pas poster tout le code sur le journal car ça l’aurait rendu long et indigeste.

J’ai peut-être eu tort.

Sauf qu’avec la vieillesse vient la sagesse.

À combien évalue-t-on l’espérance de vie d’une distribution ?

En plus du package.use, il y a le package.keyword qui permet de sélectionner des versions instables de certains paquets seulement. Attention néanmoins, il faut parfois ajouter certaine dépendance, mais portage vous le dira. Il y a aussi package.mask pour masquer un paquet ou une version.

Pour chaque ligne on peut écrire :
=app-editors/vim-2.35
>app-editors/vim-2.35
…

Ce qui en fonction du fichier imposera ou interdira l’utilisation de vim en version 2.35. Ou les versions strictement supérieure…

Il faut passer du temps au début, mais après, c’est que du bonheur. Enfin au coup de gueule près.

J’ai a peu prêt le même ressenti.

J’ajouterai, un exemple sur wine. À un moment, il y avait un bug pour jouer à DIII. Et il fallait patcher le source avant installation. La solution est d’une simplicité effrayante, il suffit de copier les patchs dans :
/etc/portage/patches/app-emulation/wine/ et emerge se débrouille. Quand les patch sont appliqué dans l’appli, il suffit d’effacer ces fichiers.
Tout fonctionne ainsi de manière simple.

Dans tous les journaux sur des distributions tu trouvais des commentaires pour dire qu'Arch c'est mieux.

[vendredi]
Ça c’est parce que nous, on sait que gentoo c’est mieux. Pas besoin de le dire pour s’en convaincre… ;-)
[/vendredi]

Je conseillerais plutôt testing.

J’avais lu, il y a quelques années, que sid si elle cassait ce n’était jamais pour longtemps. Alors que testing, si un bug est introduit, il faut que la correction passe par sid ce qui peut prendre du temps.

Et sinon, avec des vrais arguments, ca donne quoi ?

N’est-on pas vendredi ?

C'est que par rapport à plusieurs années en arrières, je trouve qu'on entend beaucoup parler de Arch et bien moins de Gentoo.

Il n’y a plus de nouveauté, il n’y a pas de version tout les 6 mois, donc peu de news, peu de problème. On entend surtout parler de Arch en ce moment à cause de systemd, sinon, c’est une distrib avec une base installé d’utilisateur qui évolue peu. Ce genre de coup de gueule, ça m’arrive tous les 2 ans, suite à un problème sur xorg… Un flag que je suis le seul à mettre en même temps qu’un autre sur un autre paquet. Il est impossible de tester toute les combinaisons de flag, arch vu le nombre de possibilité. Et c’est d’ailleurs très rare.

J'ai l'impression que la première a séduit pas mal d'adeptes de la seconde, et il faut dire qu'elles partagent une certaine philosophie.

C’est possible qu’une partie soit parti. À l’époque, j’avais voulu tester Arch, et ce n’est pas aussi simple d’être souple. Après il y a ma connaissance de gentoo et ma découverte d’Arch, toujours est-il que je ne peux pas simplement avoir kdevelop avec le support cvs, git mais pas svn sous Arch en utilisant normalement le système de paquet.

Pour les utilisateurs qui cherchent une rolling release, je les oriente plutôt vers debian/sid, qui est pas mal, à part en période de freeze où là, ça bouge plus en rolling ;-)

En cherchant à retrouver le dernier CD d’install je m’aperçois qu’il date du 19 septembre 2012… le précédent c’était 2010 je crois. Pas eu de news.

Non.
Arch, j’ai l’impression d’une distribution bricolée, là ou gentoo à l’air propre. Pour une rolling binaire autant prendre debian/sid.

Salut,
j’ai eu ce constat après 10 ans ensemble, et deux ou trois gros coup de gueule. Mais finalement, est-ce mieux ailleurs ? Et c’est là, que finalement je reste. C’est ça la passion, de temps en temps tu exploses, mais sans ta dose tu es perdu. Et je suis sûr de ne pas retrouver mieux ailleurs. À chaque tentative d’infidélité, je me rends compte que c’était mieux, alors je reviens et elle m’accueille toujours les bras ouverts sans ressentiment.

Pour le mariage, je parle bien sûr de mon mariage avec gentoo, mon autre mariage fonctionne un peu différemment.

Merci, c’est gentil.

Je te prie de m’excuser si je me suis emporté. Je réagissais à cette phrase :

Ce à quoi il va répondre que ce n'est pas parce qu'il écoute la socket qu'il est prêt.

Qui sous entend, de la connivence entre deux personnes qui ont compris et quelqu’un a qui ce n’est même pas la peine d’expliquer. Ce n’était sans doute pas ton propos. Donc je réitère mes excuses pour ma petite phrase mesquine.

Je suis incapable de coder une BD, mais synchroniser un démarrage me semble plus simple. Peut-être une question de cœur de métier.

Avec des remarques comme ca on serait tous en train de coder en assembleur …

Je te parle de conception logiciel tu me parles langage et implémentation… pas tout à fait la même chose.

Pour illustrer mon propos, je me suis fendu d’une implémentation simple de la bonne façon de faire à mes yeux. Qui ne me semble pas très compliquée.

main.c :

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

void demon()
  {
   sleep(60);
  }

void fils()
  {
   pid_t l_pid;

   printf("Debut du fils\n");
   /* Initialisation */

   /* Bricolage */
   printf("Debut du bricolage\n");
   sleep(10);
   printf("Fin du bricolage\n");

   /* Pret */
   printf("Fils %d\n",getpid());
   l_pid = setsid(); /* A partir de la, le process n'est plus associe a un terminal */
   printf("setsid() = %d\n",l_pid); /* Les printf fonctionnent puisque herite du premier fork */
   sleep(10);
   printf("Enfin pret.\n");


   /* Ferme les flux standard */
   close(0);
   close(1);
   close(2);

   l_pid = fork();

   switch (l_pid)
     {
      case -1:
         /* Soyons bourrin */
         exit(1);
      case 0:
         demon();
         exit(0);
      default:
         /* Synchronise le pere */
         exit(0);
     }
  }

void pere(pid_t p_pid)
  {
   /* Attente du fils */
   printf("Attente du fils\n");
   wait(p_pid);
   printf("Fin de l'attente\n");
  }

int main()
  {
   pid_t l_pid;

   l_pid = fork();
   switch (l_pid)
     {
      case -1:
         printf("Fork fail\n");
         return 1;
      case 0:
         fils();
         printf("Fin du deamon\n");
         return 0;
      default:
         pere(l_pid);
     }
   printf("Fils en demon\n");

   return 0;
  }

On va utiliser 2 terminaux. Un avec un watch, et l’autre pour avec la commande lancée et la compilation.

Dans le terminal 1, on compile :

$ gcc main.c -o dem
$ 

Sur le 2 on surveille les processus :

$ watch "(ps -u user | grep dem)"

On démarre le démon sur le terminal 1 :

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils

Pendant ce temps sur le terminal 2 :

 5597 pts/7    00:00:00 dem
 5598 pts/7    00:00:00 dem

Au bout de 10s :
Term 1

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils
Fin du bricolage
Fils 5598
setsid() = 5598

Term 2

 5597 pts/7    00:00:00 dem
 5598 ?        00:00:00 dem

Enfin, la dernière étape :
Term 1

$ ./dem
Debut du fils
Debut du bricolage
Attente du fils
Fin du bricolage
Fils 5598
setsid() = 5598
Enfin pret.
Fin de l'attente
Fils en demon
$ 

Term 2

5661 ?        00:00:00 dem

Pour résumer, on a un fork, le père attend sont fils. Le fils créé son groupe de session setsid, puis fork. Le nouveau fils est détaché, il ne se terminera pas avec son père. Le premier fils se termine, rendant la main au père initial. On voit ici, que si l’initialisation est faite au bricolage, le dernier fils héritant du contexte de son père. On peut rendre la main quand on a fini de s’initialiser, d’ouvrir ses socket…

Édition: correction mise en page.

Ca serait possible, mais c'est assez compliqué à faire bien, et aurait besoin d'etre fait dans chaque démon.

Bah oui, comme chaque programme fait attention à ne pas faire de bug. C’est un choix de conception du démon ou un bug. Je trouve louche que tu me dises c’est compliqué a bien faire, alors on laisse le système de démarrage palier à notre problème de conception…
Et pour répondre à un message de grumk un peu plus bas, ce n’est pas parce que tout le monde fait ça que c’est la meilleur solution. Sinon, on taillerait encore les branches avec des silex.

Et puis ca nécessite de gérer manuellement les dépendances, en listant tout ce qui a besoin de postgresql.

En quoi c’est manuel, prenons le cas openrc, tu as une fonction qui donne les dépendances dont tu as besoin. Donc openrc démarre d’abord tes dépendances avant de te démarrer. Ne me dit pas que systemd palie tout seul à ça, puisque à moins qu’il bind tous les ports sur toute les interfaces, il faut bien lui spécifier quelques part. Pour systemd c’est dans la config de postgres que tu dis qu’il utilise tel port… alors qu’avec openrc c’est dans la config de bacula que tu dis qu’il a besoin de postgres. Oui, j’admets qu’il faut écrire dépend de postgres une fois par service l’utilisant dans un cas. Mais est-ce si compliqué ?

Avec systemd il n'y a pas à gerer ces dépendances, on doit lui dire que postgresql utilise une socket, mais c'est tout, on a pas besoin de lui dire qu'un service va utiliser postgresql.

Effectivement. Mais comme je répond au dessus, est-ce compliqué ou long à faire ?

La facon dont le fait systemd permet aussi, si on lui demande, de ne démarrer le démon que si quelqu'un tente de l'utiliser.

Ça inet le faisait. Mais dans ce cas le service ne pouvait pas être lancé en mode démon ce qui semble le cas pour systemd ce qui est un avantage à ce dernier.

Je comprend mieux certains aspect, mais je pense quand même que systemd fait trop de chose. Qui vivra verra.

Merci d’avoir répondu à ma question. Je pense quand même qu’un démon devrait répondre quand il est prêt.
Ex :

lanceur 
   |
   ->  démon
         |
        fork ------
    père |        | fils
         |      lit la conf
         |        |
         |      bricole (un certain temps)
         |        |
         |      est prêt
         |        |
         |      Se détache du père et préviens qu’il peut terminer
  se termine <----|
         |        |
   |------        |
   V              | (continue sa vie)
lanceur
démarre
service
suivant

Y a-t-il une raison de ne pas démarrer un démon comme ci-dessus ? Après tout, si un service prend son temps pour démarrer, ça n’impacte que les services qui en dépendent. Un démarrage en parallèle, ne devrait pas ralentir tant que ça.

On s’éloigne de ce dont on parle. Je vais te resituer le débat.
Totof2000 à écrit :

En quoi systemd répond à ça ? Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la faute au système de démarrage, mais au service en lui même.

gnumdk à répondu :

http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

Signifiant (j’ai la flemme de traduire) :

Socket activation

Socket activation occurs when a service allows systemd to listen for connections to a specific socket and, when systemd receives a connection on that socket, it starts the service. To do this, the upstream source needs to have some minor coding work to let systemd listen for connections on the socket and there needs to be a .socket file in %{_lib}/systemd/system/ that tells systemd to listen to that socket and what to start when a connection is received. This is similar in function to inetd and some, but not all, services coded to work with inetd will work with socket activation. Simila to inetd, using socket activation for on-demand loading will impose a startup time penalty so we currently do not use this feature in Fedora.

However, socket activation can also be used to allow parallel startup of services. If a service supports systemd socket activation as described above and we additionally start it explicitly on boot, then systemd will start it but allow things that depend on it to startup at the same time. If the dependent service makes a request to the socket activatable service before it has come up, then systemd will cause the request to wait until the socket activatable service has come up and can process the request. To achieve this effect, the service must be socket activatable as described above, the .service file for the service needs to have a Wants= line for the .socket, and the service must autostart. Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart.

In practical terms this means if the upstream tarball ships with a socket file you need to contact FESCo to get permission to enable your service on boot. Once you have permission, you can package the .socket file and use the systemd scriptlets that enable the service by default. You need to also check the .service file to make sure it has a Wants= entry on the .socket file as that ensures that starting the service will also inform systemd of the socket. 

Marotte a ajouté :

L'exemple du sleep est mal choisi. En attendant, sur une Squeeze je suis obligé de (re)démarrer snort et bacula (qui utilisent postgres) dans rc.local si je veux être sûr qu'ils soient bien démarrés au boot.

/Me a répondu (Je retire le cas 2 qui était en fait une boutade) :

Si le démon postgres rend la main au script avant d’être opérationnel, c’est un problème de postgres. 

Marotte a sauté sur l’occasion pour pourrir les scripts du cas 2 mais sans répondre à la vrai interrogation (vois ci-dessus) :

/Me a précisé que le cas 2 était un fake, et demandé :

Ce que je voudrais, c’est que tu m’expliques comment dans le cas 1, (…), systemd est mieux que un script d’init. Comment systemd après avoir démarrer le démon, et que celui-ci rend la main, sait-il si oui ou non le service est fonctionnel ?

gnumdk me prend de haut, sans répondre à la question :

Je vais pas poster mon lien sur les "sockets activations" tous les 3 commentaires…

Je passe sur l’humour de Michel qui n’apporte rien au débat.

En attendant, je n’ai toujours pas compris comment systemd va permettre à Marotte de ne pas avoir à redémarrer bacula si postgress rend la main à systemd. Je ne vois pas comment systemd peut faire mieux qu’un script.
Quelqu’un aurait-il assez de patience pour m’expliquer ?

Le cas que tu as retenu est de lancer un démon dans un script ainsi :

#!/bin/bash

case "$1"
start)
demon -mon_option &
;;
…

On est d’accord que c’est de l’incompétence de la personne qui a écrit le script. Dans l’exemple ci dessous le démon est lancé comme dans mon cas 1.

Ce que je voudrais, c’est que tu m’expliques comment dans le cas 1, puisque le cas 2 est impossible, systemd est mieux que un script d’init. Comment systemd après avoir démarrer le démon, et que celui-ci rend la main, sait-il si oui ou non le service est fonctionnel ?
Explique moi comment ça empêchera d’avoir une tempo, ou un redémarrage pour bacula dans ton cas.

Si le démon postgress rend la main au script avant d’être opérationnel, c’est un problème de postgress. Je suis sûr qu’il y a un tracker de bug quelque part.
Sinon, si le démon est lancé par le script en tâche de fond (&) alors c’est un bug du script d’init. Mais ce n’est pas la faute du système de démarrage. En plus ton contournement pourrait ne pas marcher si le boot allait plus vite ou autre… pas très safe comme méthode.

La différence c’est que openrc lance le démon. Alors que systemd, s’installe sur la socket pour démarrer le service quand il sera demandé (si j’ai bien compris). Il y a une différence de philosophie.
Dans les exemples sur gentoo, si tu démarres un service qui a besoin d’un autre service, la dépendance sera activé puis on lance le service voulu. Si un service qui n’a pas été demandé à démarrer par l’administrateur, mais qui l’a été en tant que dépendance d’un autre service et qu’on arrête se dit service, alors le service dépendant sera arrêté à la condition qu’aucun autre service ne dépende de lui. Déjà vu avec RPC.
Ce qu’il y a de sourd dans ce dialogue, c’est que toi tu dis que être contre systemd c’est être contre la simplicité, alors que ce n’est pas forcément le cas. Pour l’instant, rien ne me prouve que systemd est mieux que openrc, bien que se dernier soit du script…

Ce qui me gène dans systemD c’est l’éloignement de 1 outil qui fait une chose, mais qui la fait bien. Avant, si on avait une faille dans un service réseau, on pouvait désactiver ce service en attendant une correction. Après, si une faille dans la couche réseau de systemd apparait, et je serais étonné que ça n’arrive jamais, impossible de le désactiver la distribution ne l’a pas prévu…
Un autre point qui me gène, c’est que quand tu as fini de démarrer, ben en fait, il en reste encore… (un peu comme paic citron) mais là c’est dans le mauvais sens. Ça fait un peu comme winXP, comme quoi microsoft avait 10 ans d’avance.
Quelle sera la prochaine évolution ? Inclure wayland dans systemd pour plus de réactivité ?
« Je me fais vraiment trop vieux pour ces conneries. »

Ça veut dire exécuter 2 apaches démarrés avec des utilisateurs différents. Je ne sais pas si apache sait faire, c’est certainement possible, mais je ne vois pas comment un CMS pourrait imposer une configuration système à l’administrateur. As-tu une idée ?

Bah, pour qu’il passe le conseil de vérification, il devra cité la revu « Pain & gourmandise » et son article sur le sujet. Parce que un journaliste sait mieux qu’un professionnel pour wikipedia.

Tu es au bon endroit pour prendre des cours de français… les linuxfrien sont pointilleux, et à force on progresse. Même moi, et je partais de très loin, j’ai fait beaucoup de progrès.

Pourquoi prendre gentoo comme LA référence de la distro compliquée ?
Elle est :
* Stable
* Très bien documentée
* Un excellent système de démarrage ;-)

Je trouve personnellement plus compliqué d’avoir un système stable avec ubuntu qu’avec gentoo.