Actualités & Annonces de l'équipe de développement et des administrateurs du forum.

Drôle de maj systemd !

#41Messageil y a 9 ans

Erwan c'est la 219-5.1 ici & comme je l'avais remarqué avec <downgrade>, il semblerait qu'il n'y ait + de 218 dans le dépôt unstable de manjaro..

Drôle de maj systemd !

#42Messageil y a 9 ans

Intéressant, cela pourrait signifier que ta version en ".1" donc celle ayant fait l'objet d'une révision mineure de la 219-5 serait -peut-être- la source de nos soucis actuels. Pourquoi n’essaierais-tu pas d'installer la version originelle à savoir celle ci : systemd-219-5-x86_64.pkg.tar.xz dont on trouve le paquet dans le la page du lien donné par ewolnux plus haut ? C'est une piste un peu bizarre, voir improbable mais si ça peut permettre de cerner encore un peu plus le problème, ça vaut franchement le coup :bien Si on fait un bilan "à la louche" on peut dire d'après les données que nous avons que la version de systemd qui est tout à fait clean au regard de notre problème actuelle est bien la 219-5 et uniquement celle-là puisque fassil reproduit le bug du démarrage, même minoré, en 219-5.1 me trompe-je ?
Dernière modification par Erwanil y a 9 ans, modifié au total 1 fois.

Drôle de maj systemd !

#43Messageil y a 9 ans

Erwan a écrit :Intéressant, cela pourrait signifier que ta version en ".1" donc celle ayant fait l'objet d'une révision mineure de la 219-5 serait -peut-être- la source de nos soucis actuels.

Je ne comprends pas trop, tu dis plus haut qu'en 219-6 tu as le problème et que avec 219-5 le problème a disparu. Donc le problème est présent dans 219-6 (peut-être depuis 219-5.1).

Drôle de maj systemd !

#44Messageil y a 9 ans

ewolnux a écrit :
Erwan a écrit :Intéressant, cela pourrait signifier que ta version en ".1" donc celle ayant fait l'objet d'une révision mineure de la 219-5 serait -peut-être- la source de nos soucis actuels.

Je ne comprends pas trop, tu dis plus haut qu'en 219-6 tu as le problème et que avec 219-5 le problème a disparu. Donc le problème est présent dans 219-6 (peut-être depuis 219-5.1).
Exactement, peut-être l'ai-je mal exprimé mais on sait maintenant que 219-6 pose problème et qu'en revanche 219-5 n'en pose aucun et d'après l'expérience de fassil, on peut imaginer que 219-5.1 pourrait être le "départ de feu" répliqué dans la version ultérieure (219-6)

Drôle de maj systemd !

#45Messageil y a 9 ans

Moi aussi je me suis mal exprimé, je voulais corriger et puis je suis passé à autre chose :clindoeil:

Drôle de maj systemd !

#46Messageil y a 9 ans

ewolnux a écrit :Moi aussi je me suis mal exprimé, je voulais corriger et puis je suis passé à autre chose :clindoeil:

Bah, c'est plutôt pas mal de passer d'un truc à un autre ou de tout faire en même temps :clindoeil: Perso et à l'inverse de mon processeur, je suis incapable de faire plusieurs choses à la fois :triste:
Maintenant, je sais pas comment ce sera géré à l'inter mais vu que le problème n'est pas bloquant, j'imagine qu'il vont continuer les mises à jours de systemd, et passer tout ça dans testing puis stable, jusqu'à celle, miraculeuse, qui résoudra cette lenteur au démarrage. Perso, j'ai cadenassé l'upgrade de systemd, en attendant mieux. Et puis 6 à 11 secondes, même si c'est pas la fin du monde, c'est trop lorsque l'on a l'habitude de démarrer à la vitesse de l'éclair :gsourire:

Drôle de maj systemd !

#47Messageil y a 9 ans

comme le dit "Kirek" a l'inter
les services sont lancés en parallèle donc il ne faut pas additionner le temps de ce service unité /dev/sda :!:

le temps qu'il est actif 12 autres services sont lancés ce qui est visible avec :

systemd-analyze plot > plot.svg

fichier svg visible avec le navigateur web
ici de 5.5 à 9.5 secondes, en rien il ne bloque les autres
ce qui compte c'est + l'escalier du service suivant et la c'est infime :)
Image

Drôle de maj systemd !

#48Messageil y a 9 ans

je peux confirmer que c'est le passage de 219.5 à 219.6 qui introduit ça, mais en ce qui me concerne, bien que le temps de démarrage de ce service soit plutôt long, ça ne se voit pas au boot (le plot.svg montre bien que d'autres trucs démarrent en parallèle, et que c'est fini bien avant le chargement des modules).
le seul truc qui me chiffonne, c'est que dev-sda1.device mette autant de temps à démarrer une partition de 20 Go, alors que dev-sda3.device démarre intantanément malgré les 980 Go de la partition correspondante...

on va attendre de voir un éventuel correctif...

Drôle de maj systemd !

#49Messageil y a 9 ans

Loubrix a écrit :que dev-sda1.device mette autant de temps à démarrer une partition de 20 Go, alors que dev-sda3.device démarre instantanément malgré les 980 Go

En fait c'est la partition "système" qui prend du temps c'est la fonction qui compte pas la taille
Loubrix a écrit : à démarrer une partition

elle est bien démarrée sinon tout serait bloqué, par contre il va peut-être chercher des infos (comme lecture de /etc/os-release) qui prend du temps ...
Dernière modification par papajokeil y a 9 ans, modifié au total 1 fois.

Drôle de maj systemd !

#50Messageil y a 9 ans

Je viens de faire le test "plot.svg" temps total du démarrage, c'est à dire, userspace + kernel :
sur systemd 219-5 : 20 secondes
Sur systemd 219-6 : 18 secondes
Les résultats sont sans appel, j'avais pourtant l'impression que ça démarrait moins vite en 219-6, comme quoi l'illusion et l’auto-persuasion font partie du système complexe qui nous sert de cerveau :mrgreen: Résolu, pour ce qui me concerne et je reste avec 219-6 que je viens de réinstaller !
Dernière modification par Erwanil y a 9 ans, modifié au total 1 fois.

Drôle de maj systemd !

#51Messageil y a 9 ans

Erwan a écrit :Les résultats sont sans appel, j'avais pourtant l'impression que ça démarrait moins vite en 219-5

attention "systemd-journal-flush" est variable
edit: si la taille du journal varie flush de même
Dernière modification par papajokeil y a 9 ans, modifié au total 1 fois.

Drôle de maj systemd !

#52Messageil y a 9 ans

Ce qui veut dire qu'il peut y avoir une variation entre deux démarrages sur ce service ? J'ai fait le test deux fois sur chacun des deux systemd et les résultats concordent.

Drôle de maj systemd !

#53Messageil y a 9 ans

en fait, la parallélisation sous Systemd est assez proche de la perfection (c'est ce que j'en sors quand j'épluche le truc sous toutes ses coutures); on peut très bien rajouter un service, que celui-ci soit très long, mais si tout le reste continue à démarrer normalement à coté, ça change rien au temps de boot...
l'option qui permet de voir ce que Systemd considère comme étant trop long est "critical-chain", et perso je n'ai que ModemManager qui apparaît dedans (je peux pas le désactiver, j'en ai besoin quand je me sers de mon smartphone comme modem).
les temps qui sont donnés dans "systemd-analyze blame" sont les temps pour chaque UNIT; ils ne s'additionnent pas pour obtenir le temps total du démarrage, déjà parce qu'ils démarrent en parallèle, et aussi parce que certains services sont encore en train de démarrer alors que le bureau est affiché (et c'est ce dont on tient compte pour la vitesse de boot).

enfin bref: on se rend compte qu'on a un truc en plus (dev-sdaX.device) qui prend beaucoup de temps, et on croie que c'est un bug; mais on oublie de se dire que ce dev-sdaX.device a peut-être remplacé autre chose (ou pris une partie du boulot d'autre chose), et on ne s'est pas interrogé pour savoir si une autre UNIT n'avait pas disparu, ou ne prenait pas beaucoup moins de temps...

Drôle de maj systemd !

#54Messageil y a 9 ans

Finalement je suis passé à systemd 219-6 et je n'ai vu aucun ralentissement dans le boot.

┌──[04-05-2015 11:25:12] [thierry@pc-thierry] ~ 
└──[$] → systemd-analyze
Startup finished in 1.461s (kernel) + 458ms (userspace) = 1.919s
┌──[04-05-2015 11:25:19] [thierry@pc-thierry] ~
└──[$] → systemd-analyze blame
           181ms dev-sda5.device
            80ms syslog-ng.service
            79ms NetworkManager.service
            57ms systemd-fsck@dev-disk-by\x2duuid-2a3fadeb\x2d57d0\x2d4d31\x2d8d77\x2dc94d5f551
            49ms systemd-udevd.service
            48ms systemd-vconsole-setup.service
            43ms systemd-journald.service
            39ms colord.service
            34ms systemd-binfmt.service
            33ms ntpd.service
            30ms systemd-logind.service
            29ms udisks2.service
            27ms systemd-journal-flush.service
            27ms alsa-restore.service
            19ms systemd-udev-trigger.service
            18ms polkit.service
            15ms user@1000.service
            15ms kmod-static-nodes.service
            15ms systemd-remount-fs.service
            14ms user@997.service
            14ms dev-hugepages.mount
            12ms avahi-daemon.service
            12ms home-commune.mount
            11ms systemd-sysctl.service
            11ms tmp.mount
            10ms systemd-modules-load.service
            10ms sys-kernel-debug.mount
            10ms systemd-tmpfiles-setup-dev.service
             6ms upower.service
             5ms systemd-random-seed.service
             5ms sys-kernel-config.mount
             4ms proc-sys-fs-binfmt_misc.mount
             4ms systemd-backlight@backlight:acpi_video0.service
             3ms systemd-backlight@backlight:acpi_video5.service
             3ms systemd-backlight@backlight:acpi_video3.service
             3ms systemd-backlight@backlight:acpi_video2.service
             3ms systemd-backlight@backlight:acpi_video7.service
             3ms systemd-backlight@backlight:acpi_video4.service
             3ms systemd-backlight@backlight:acpi_video1.service
             2ms dev-disk-by\x2duuid-4aa131f4\x2de9ce\x2d44b3\x2dbb66\x2d948ca44152f1.swap
             2ms systemd-tmpfiles-setup.service
             2ms systemd-update-utmp.service
             2ms systemd-backlight@backlight:acpi_video6.service
             1ms dev-mqueue.mount
             1ms systemd-user-sessions.service
Répondre