Zeige mal die Ausgabe von
cat /etc/apt/apt.conf.d/10periodic
Mal sehen, was da drin steht.
Anmeldungsdatum: Beiträge: 3322 Wohnort: Berlin |
Zeige mal die Ausgabe von cat /etc/apt/apt.conf.d/10periodic Mal sehen, was da drin steht. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
Okay, da ist bei mir der Standardwert "1800", also 30 Minuten eingestellt. Wenn ich das aber jetzt auf "0" stelle, dann dürfte mein Rechner doch noch langsamer starten, oder? 🙄 Ich dachte, Du meintest, der Rechner soll erst später nach Aktualisierungen Ausschau halten und nicht schon sofort beim Hochfahren, wenn er ohnehin so viel zu tun hat? Oder hab ich da was falsch verstanden? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
Gerne: APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::Unattended-Upgrade "1"; |
Anmeldungsdatum: Beiträge: 3322 Wohnort: Berlin |
Wenn da schon 1800 bzw. 30 min eingestellt sind, dann wird es das vermutlich nicht sein. Die Ausgabe von cat /etc/apt/apt.conf.d/10periodic sieht bei mir so aus: frank@frank-ThinkPad-T430:~$ cat /etc/apt/apt.conf.d/10periodic APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::Unattended-Upgrade "0"; frank@frank-ThinkPad-T430:~$ . Also nicht soviel anders, außer bei den Unattended. Hm, mal sehen |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
Bei mir sind halt noch automatische Updates zugelassen ... das kann ich gerne rausnehmen, aber ob das was ändert ...? |
Anmeldungsdatum: Beiträge: 3322 Wohnort: Berlin |
Das wird wahrscheinlich nicht viel ändern. Versuche mal das von Hakel umzusetzten, also den Befehl systemd-analyze plot > graph.svg im Terminal eingeben und dann einmal neustarten. In deinem home-Verzeichnis findest du dann eine Datei namens "graph.svg" die kannst du mit dem mit dem Browser öffnen.
Edit: Neustart ist nicht nötig. In dem Moment, wo der Befehl im Terminal abgesetzt wird, wird die Datei neu erzeugt, und vorhanden mit gleichem Namen überschrieben, gerade getestet. Dann wäre es am nächsten Montag sinnvoll, diesen Befehl als erste Arbeit abzusetzten und dann in Ruhe die Grafik anschauen. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
So habe ich das auch verstanden. Der Befehl erstellt quasi im Nachhinein eine Grafik des letzten Systemstarts. Ich werd's am kommenden Montag durchführen und berichten. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
So, wir haben wieder Montag und hier ist mein Bericht: Ich habe eine Analyse gefertigt nach dem ersten Systemstart am Montag sowie zum Vergleich eine zweite Analyse nach dem zweiten Systemstart. Der Befehl systemd-analyze plot > graph.svg ist ja ganz nett und die Grafik sehr beeindruckend, aber - wie ich finde - wenig übersichtlich. Trotzdem besten Dank an hakel2020, der mich dadurch auf den Befehl systemd-analyze brachte, den ich dann der besseren Übersicht halber für dieses Forum mit anderen Optionen ausgeführt habe. Hier meine gesamte Zeitdauer für den 1. Systemstart am Montag: systemd-analyze time Startup finished in 14.770s (firmware) + 11.661s (loader) + 21.147s (kernel) + 8min 54.624s (userspace) = 9min 42.203s graphical.target reached after 30.995s in userspace Im Vergleich dazu die gesamte Zeitdauer für den 2. Systemstart am Montag: systemd-analyze time Startup finished in 14.791s (firmware) + 11.655s (loader) + 20.668s (kernel) + 9.193s (userspace) = 56.309s graphical.target reached after 8.261s in userspace Hier wird schon mal klar, dass die zeitliche Verzögerung in der Initialisierung des Userspace zu suchen ist. Weitere Details fand ich mittels der Option blame: systemd-analyze blame 8min 53.252s fstrim.service 29.285s apt-daily.service 28.740s plymouth-quit-wait.service Diese drei Einträge waren beim zweiten Systemstart gar nicht mehr zu finden. Welche davon täglich wiederkehren und welche nur wöchentlich, konnte ich zwar noch nicht eruieren, aber ich schätze mal, dass zumindest fstrim.service den Montagsblues verursacht. Also habe ich mal recherchiert, was dieser Dienst bewirkt und wurde unter https://wiki.ubuntuusers.de/SSD/TRIM/#Automatisches-TRIM-ab-Ubuntu-14-04-LTS fündig. Wenn ich richtig lese, ist TRIM standardmäßig bei Ubuntu aktiv, stellt eine wichtige Sicherheitsfunktion für SSDs dar und sollte besser nicht deaktiviert werden. Wenn dem so ist und dies also alles als normal anzusehen ist, frage ich mich allerdings, warum ich dann der einzige Ubuntu-User zu sein scheine, bei dem dieser Montagsblues deutlich zutage tritt. 🙄 Da müsste doch dann eigentlich jeder Ubuntu-User montags einen sehr langen Systemstart bemerken, oder? |
Anmeldungsdatum: Beiträge: 1488 Wohnort: Ruhrgebeat |
Hallo win-linux-umsteiger, hast Du das Ganze mal wie empfohlen mit einem Live-System (vorzugsweise 20.04) getestet? Bitte beachten: Bei der aktuellen LTS-Version ist auch ein neuerer Kernel enthalten! Grüße schollsky |
Anmeldungsdatum: Beiträge: 3322 Wohnort: Berlin |
Über 8 Minuten trimmen ist schon heftig. Festplatte defekt? → Festplattenstatus Trim "spinnt" → SSD/TRIM/Testen |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
|
Anmeldungsdatum: Beiträge: 1169 |
Na also, dann ist ja alles klar! Die Plot kannst du auch hier veröffentlichen, bei dir ist die Sache natürlich ganz einfach - also überflüssig. Jetzt mußt du nur noch rausfinden, ob die Platte defekt ist oder der Trim Dienst. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 111 Wohnort: Kitzingen |
Bin die Anleitung Punkt für Punkt durchgegangen, habe smartmontools installiert. Aber dann stieß ich bereits auf das erste Problem beim Aufruf von: sudo smartctl -a /dev/sda ... Device is: Not in smartctl database ... Also habe ich alle manuellen Update-Möglichkeiten angewandt, die ich finden konnte, nämlich: sed -i "/^SRCEXPR/{s#=.*#='https://sourceforge.net/p/smartmontools/code/HEAD/tree/\$location/smartmontools/drivedb.h?format=raw'#}" $(which update-smart-drivedb) wget https://www.smartmontools.org/export/latest/branches/RELEASE_7_0_DRIVEDB/smartmontools/drivedb.h sudo mv /var/lib/smartmontools/drivedb/drivedb.h /var/lib/smartmontools/drivedb/drivedb.h.bak sudo mv drivedb.h /var/lib/smartmontools/drivedb/ sudo chown -c root:root /var/lib/smartmontools/drivedb/drivedb.h sudo update-smart-drivedb Aber nix half, es bleibt bei sudo smartctl -a /dev/sda ... Device is: Not in smartctl database ... Und so kann ich den Festplattenstatus wohl nicht überprüfen, oder? 😢 |
Anmeldungsdatum: Beiträge: 1169 |
Es liegt vermutlich einfach daran, daß deine Platte verschlüsselt ist. Bei Bootproblemen sollte man immer auch Plymouth deaktivieren, damit man ohne Umwege Fehlermeldungen erhält. Die Plot Grafik ist übrigens prima, da kann man nicht meckern. 👍 Ich würde diesen Thread hier zumachen und einen neuen Thread aufmachen. Wichtig ist ein vernünftiger Betreff. "SSD plus Trim plus Verschlüselung" z.B., da muß ein Spezialist her. Das mit dem Montag ist ja geklärt. Du solltest übrigens unbedingt auf 20.04 wechseln, damit werden einige Bootprobleme behoben. 18.04 war nicht gut ... 🐸 |