Ist ja nicht auszuschliessen, dass da intern was geändert wurde.
Eventuell gab es durch den schnellen Start Probleme, so dass da eine gewisse Karenzzeit implementiert wurde (reine Spekulation).
Gründe dafür kann es viele geben.
Im Gegensatz zum alten Sysvinit bei dem Dienste sequentiell gestartet wurden, werden heutzutage bei systemd die Dienste, wenn möglich parallel gestartet. Es kann durchaus sein, dass der NetzwerkManager in dieser Zeit auf den einen oder anderen Dienst warten muss. Dann wäre höchtwahrscheinlich nicht ein NetzwerkManager update dafür verantwortlich, sondern ein systemd update.
Verschlimmbessert finde ich jetzt doch arg überzogen.
Wie oft startest du denn deinen Rechner neu?
-
-
Du hast recht, Systemd könnte dafür auch verantwortlich sein. Da gab es in letzter Zeit auch ein Update, ich weiß jedoch nicht mehr ob die verlängerte Wartezeit erst deit dem Update auftritt.
Nun, der Laptop steht hier herum und wenn man mal was machen möchte, schaltet man ihn ein, dananch wieder aus. Also auch öfter am Tag.
Normalerweise startet er schneller als ein Tablet....Gruß
-
Ich hatte ein ähnliches Problem. Von einem Tag auf den anderen, nix mehr mit schnellem booten, sondern gefühlte Ewigkeiten der Startbildschirm mit den 3 Punkten.
Bei mir war es der wicked.service, kein Ahnung warum der auf einmal aktiv war, ich selbst habe schon lange kein Programm mehr installiert!
Wieder auf den normalen Network Manager gesetzt (yast, netzwerkeinstellungen-globale optionen), seitdem läuft es wieder normal. -
Ich habe das gerade mal kontrolliert. Wicked ist definitiv deaktiviert und tauchte auch in keinem Protokoll auf.
Werde wohl damit leben müssen... -
Poste einmal:
Codesystemd-analyze critical-chain
Wobei das Netzwerk bei mir auch ein paar Sekunden braucht:Code
Alles anzeigensystemd-analyze blame 4.550s wicked.service 1.545s systemd-udev-settle.service 729ms dev-sdb1.device 320ms udisks2.service 306ms postfix.service 266ms alsa-restore.service 203ms SuSEfirewall2.service 200ms vboxdrv.service 178ms ecbd.service 162ms avahi-daemon.service 155ms SuSEfirewall2_init.serviceZum lesen:
NetworkManager - ArchWiki -
Code
Alles anzeigensystemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @6.966s └─display-manager.service @6.332s +631ms └─time-sync.target @6.331s └─ntpd.service @6.298s +33ms └─network.target @6.293s └─NetworkManager.service @987ms +149ms └─basic.target @948ms └─timers.target @948ms └─systemd-tmpfiles-clean.timer @948ms └─sysinit.target @947ms └─systemd-update-utmp.service @933ms +13ms └─systemd-tmpfiles-setup.service @907ms +23ms └─local-fs.target @898ms └─var-lib-mailman.mount @446ms +445ms └─dev-disk-by\x2duuid-5b3a1175\x2d8062\x2d43ec\x2d9a89\x2dc5951784d564.device @436msDas ist die Ausgabe Erkennst du irgenwas daran?
-
Ne, alles ok.
Drücke bitte beim nächsten Computerstart einmal nach dem Grub im Plymouth Splash die ESC Taste, dann kannst Du vielleicht etwas erkennen.
-
ich habe den übeltäter über ein Bild gefunden
Codesystemd-analyze plot > boot.svgund von den 20 Sekunden die für kernel->initrd->systemd angezeigt wurden, entfielen dann fast 17 Sekunden auf wicked.serviceund dannach hab ich halt gegoogelt was das ist und wie ichs wieder wegbekomme (siehe vorherigen Post, bei mir waren es die Netzwerkeinstellungen)Das war vielleicht dilettantisch, ich gebe ja auch jederzeit zu, keine Ahnung zu haben, hat aber trotzdem zu einem zufriedenstellenden (für mich) Ergebnis geführt.Die Bootzeit für kernel-initrd-systemd liegt wieder bei <4,5sek und es funktioniert immer noch alles.
-
Ich hatte den wicked-Dienst von Anfang an in Verdacht, aber aus Post #14 :
Zitat von mairoWicked ist definitiv deaktiviert
Mit solchen Aussagen sollte man immer vorsichtig sein, gerade wenn, aus Post #18 :
Zitat von mairoich gebe ja auch jederzeit zu, keine Ahnung zu haben
Das nächste Mal lieber etwas genauer nachgucken.
-
Ich bezog mich auf meinen "Lösungsweg" das Problem auf meinem Rechner zu finden, vielleicht hätte das auch einen Nutzen haben können, für ein anderes, in der Erscheinung aber ähnlichem Problem (verlängerte Bootzeit, näch) Kernaussage meines postings war also DAS DA
Codesystemd-analyze plot > boot.svgein Hinweis von vielleicht nur eingeschränktem Nutzen, aber zumindest ungefährlich.
Aber danke für deinen Hinweis, ich werde ganz sicher kein Posting mehr machen, an dem irgendwelche Profis irgendetwas rumzukriteln haben.