Anthony Jaguenaud a écrit 1941 commentaires

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.

Personne n’a dit que les distributions avaient vocation à être exhaustives en terme d’applications libres… En gros, un petit nombre est choisi par des critères subjectifs tel que : à jour des lib., fonctionnant correctement…

Je réagi à ça.

il faut expliquer à chaque fois ce que python est un langage de programmation(c'est un exemple débile mais représentatif)

Je trouve au contraire essentiel de remettre le contexte systématiquement. Ceci au moins parce que je n’ai pas la science infuse et que quand je vois un titre de dépêche avec des noms et acronyme que je ne comprends pas, je lis le début pour voir de quoi il retourne. Et si direct il y a une comparaison avec la version précédente, ou que l’auteur pense que c’est tellement évident. Je zape ou je demande dans les commentaires de quoi on parle. Oui, je peux aller sur Wikipedia, mais si PC expert n’a pas fait un article dessus, point d’article Wikipedia (le gros TROLL ;-)). Mais ça demande un effort à plein de gens alors qu’écrire une ligne au rédacteur d’une dépêche qui connait parfaitement le domaine ça prend 5 minutes.

De mon point de vue l’intérêt est plus que limité. Ce qu’il faudrait, c’est participer à un FS standard, sans gestion d’utilisateur (trop différent entre les OS). De façon à ce qu’on puisse partager facilement des clé USB. Ça c’est un vrai besoin, et FAT32 s’est quand même vieillot !
Supporter tous les FS existant, non. Mais participer à la création d’un truc moderne et interopérable ce serait super.

Non. Je dis que une bonne dépêche de temps à autre c’est bien. Si on a 15 communiqués interne de présentation marketing, plus détailler à chaque fois qu’il y une faille, un nouveau Service Pack… ça va, effectivement être chiant. Mais avec parcimonie, je trouve ça intéressant. Je suis pour l’ouverture d’esprits. D’autant que ceux qui finissent par atterrir ici, vienne trouver des choses que d’autre site ne propose pas comme des débats techniques par exemple. Où même si on n’est pas forcément d’accord sont souvent intéressant.
Ce que j’ai retenu de la lecture de la dépêche, ce n’est pas le portage vers plusieurs CPU, mais l’unification du noyau de l’OS pour toutes les plateformes. Et que pour limiter les risques de sécurité, ils ont enfin mis un système aléatoire de placement des processus.
Ce que je n’ai pas compris en première lecture et pas approfondi, c’est l’histoire de la bitmap.
Ce qu’il me manque, c’est plus de détail sur l’unification des dll système entre toute les versions.

Dans ce cas, il faut refuser les dépêches sur BSD, Apple, les … d’automobilistes et de motards et même refuser les dépêches sur le cinéma, les rubriques nécrologiques. On devrait même effacer les commentaires de ceux qui n’écrivent pas Linux dans un commentaire… d’ailleurs, ton commentaire est hors sujet.

Blague à part, ce site à vocation à parler de ce qui tourne autour de linux, GNU/Linux et des logiciels libre. Ce qui inclue BSD, KDE, gnome, même systemd (burk)… mais également Windows, MACOS qui en tant que concurrents ont tout à fait leur place ici. Si tu veux t’enfermer dans ta bulle Linux comme le font certains pommiers dans la marque de la pomme, je pense que tu n’es pas au bon endroit et que tu devrais retourner sur un site qui ne te fera pas peur.

Tu sais, pour le x86, il va continuer à évoluer. Mais aujourd’hui, même si les CPU peuvent se brider pour faire du x86_32, ils sont plus adapté à faire du x86_64. Mais la compatibilité ascendante fonctionne. Je peux toujours faire : « MOV AH,3 » même si c’est inefficace, donc le x86_16 n’est pas mort… néanmoins, je ne vois pas beaucoup de soft compilé en 16 bits de nos jours.
Que Microsoft développe son OS dans un langage de haut niveau pour le porter facilement, je pense que ça n’étonne personne, sauf toi peut-être. Par contre, si j’ai besoin de faire une solution embarquée, c’est plus simple d’accéder aux source de linux ou BSD pour l’adapter à mes besoins.
Ce n’est pas parce qu’une chose est possible qu’elle est pertinente.

Merci PasBillPG pour ta dépêche, même si je regrette comme certains que tu n’es pas poussé assez loin les choix techniques de l’OS.

Et ça traverse les BOX qui font du NAT. Même si plusieurs utilisateurs utilisant plusieurs PC locaux font des accès distants.

Le pape est nommé par une élection. Je ne crois pas qu’il y ait dans les textes un critère par rapport à la croyance en Dieu. En tant qu’agnostique, je devrais pouvoir être pape, si les cardinaux se mettent d’accord. D’après Wikipedia, ce serait la « la constitution apostolique » qui sous-entendrait que le candidat doit être homme, et prêtre. Oui, c’est une discrimination à l’embauche, mais le Vatican étant un pays, son droit du travail n’a pas à être compatible du nôtre…

Mon fils de 7 ans à son bureau remplis d’icônes. Ça t’aide ?

Sinon, moi mon bureau est bordélique, mais sur l’ordi, je n’y met presque rien. Juste ce que je veux lancer au démarrage quand je suis obligé d’utiliser Windows. En général, c’est mon terminal qui lance mes applications en plein écran, et j’aime bien ranger mes fichiers dans des dossiers, des sous-dossier… le seul truc qui me manque c’est de pouvoir avoir plusieurs chemin pour accéder à un fichier, mais c’est par flemme (ln -s).

Elle aurait pu y aller à pied en 3 mois. Donc c’était possible.

Pour un voyage au Mexique, il y a le voilier, Colomb l’a fait.

Faut arrêter la mauvaise fois… même si ça fait des beaux trolls velus.

Ah le Charlie qu'on courait acheter et qu'on ouvrait vite fait à la page 5 pour voir ses dessins…

Est-ce le journal qui a changé ? Ou toi qui a pris un coup de vieux ? ;-)

Je ne l’ai utilisé que pour tester. Et mon emploi du temps du week-end ne m’a pas permis d’y passer beaucoup de temps.
Non, j’ai que des disques standard, un 300Go et un de 1 To.

Pour une utilisation domestique, à la maison, ça ne m’a rien apporté. Maintenant, si on revient sur la discussion sur le sandboxing qu’il y a eu la semaine dernière (je crois), je pense que cette solution est meilleure.
Dans la VM « banking », je peux aller sur le site de ma banque, sauver des fichiers, qui ne seront visible que de cette VM, du coup, je peux choisir facilement la sécurité et le regroupement des informations par groupe. Les applications douteuses sont facilement isolables.
Ça fait bizarre d’avoir plusieurs navigateurs lancés. Il faut choisir le bon en fonction du site où on va. Ce qui est non seulement un changement d’habitude, mais aussi une contrainte supplémentaire et l’utilisateur n’aime pas les contraintes. C’est pour ça que pour une utilisation personnelle, je n’y crois pas trop, les seuls qui sauront que ça existe, savent déjà comment sécurisé un minimum leur ordinateur.
Par contre, je trouve l’ensemble très prometteur pour une boîte.

Sinon, le démarrage d’une application dans une VM non démarrée, prend un peu de temps. Il faut bien démarrer la VM.

Je n’ai pas vu de soucis de performance, mais j’ai changé de config récemment :
AMD Buldozer 3.5GHz + 16Go RAM.
Si ça avait ramé, ça aurait été inquiétant.

la finalité de l'école est de permettre de trouver un boulot et non d’éduquer et de cultiver.

Pour moi, l’école doit cultiver et instruire. L’éducation ne devrait-elle pas être faites par les parents ?

Argh, dommage qu’on ne soit plus vendredi tiens ! Ça nous aurait fait un beau troll sans sexisme ni systemd…

Ils doivent lancer un exécutable

Donc thunderbird lance un exécutable (firefox) à chaque fois que je clique sur un lien. Donc il a le bon dénominateur commun, donc il doit être intégré à systemd. En même temps c’est logique, pourquoi avoir plusieurs implémentation de imap…

La seule différence entre cron et init, c'est que le premier fait ça en fonction de l'heure et le second quand on change de runlevel.

Moi je vois d’autres différences :

• Un utilisateur peut utiliser cron alors qu’il ne peut toucher à init.
• L’un est démarré par le noyau, l’autre par un démon (crond) lui même démarrer par les scripts d’init eux même démarrer par le programme init.
• L’un est le père de tous. Et même en se détachant des parents on ne peut renier cet ancêtre.
• Et sans doute d’autres.