ubuntuusers.de

VM langsamer Start

Status: Ungelöst | Ubuntu-Version: Lubuntu 18.04 (Bionic Beaver)
Antworten |

Rosika

Anmeldungsdatum:
26. Februar 2016

Beiträge: 1359

Hallo zusammen und ein Gutes Neues Jahr,

ich nutze BodhiLinux in einer VM (virt-manager mit qemu/kvm).

Anscheinend dauert der Start etwas (zu) lange, denn ich bekomme in Bodhi gleich ein Fenster mit einer error-Meldung angezeigt:

E: Efreetd cannot be connected toPlease check:
$XDG_RUNTIME_DIR /.ecore/efreetd/0
or
~/.ecore/efreetd/0
Is your system very slow on start so
efreetd cannot be connected to within
0.5sec after launch??

Und genau diese letzte Anmerkung scheint das "Problem" zu beherbergen. Denn:

Starte ich Bodhi in der VM zum 1sten Mal (nachdem ich meinen Host hochgefahren habe, meist einmal am Tage), so dauert der Start von Bodhi immer (zu) lange, und ich bekomme diese Meldung.

Fahre ich Bodhi herunter und starte später erneut, bleibt diese Fehlermeldung aus. Der Start ist auch viel schneller. Das Problem scheint eher am erstmaligen langsamen Start zu liegen als an efretd.

Deshalb meine Frage: Weiß jemand, warum der erste Start länger dauert und ob es eine Möglichkeit gibt, ihn zu beschleunigen?

Vielen Dank im voraus.

LG. Rosika

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Hallo!

Die Frage lässt sich pauschal nicht beantworten. Das hängt von einigen Faktoren ab, wie bspw. die verwendete Hardware des Host, das Format der virtuellen Festplatte, die Einstellungen der VM, Grafikeinstellungen, usw.

Prinzipiell richtet der virt-manager die VM schon sehr gut ein, wenn bei der Installation der passende OS-Typ angegeben wird. Mal so als Mini-Checkliste aus dem Stehgreif:

Host:

  • CPU, RAM ausreichend für Host UND Gast?

  • Festplatte, auf dem das Image liegt schnell genug / ausreichend Platz?

  • Grafikkarte: Treiber funktionieren? Besonderheiten beachtet?

  • verwendete Module (lsmod | grep kvm sollte mehrere Module ausgeben, siehe KVM) vorhanden?

  • Netzwerkverbindungen, Kernel-Firewall (iptables, nftables, ufw), Routen: Dienste stören sich nicht gegenseitig? (eigener dnsmasq, dockers iptables,usw)

Gast:

  • Festplattenformat der virtuellen Platte

  • zugewiesene CPU(s), RAM

  • Grafikeinstellungen (VNC, SPICE, VGA, QXL, usw.)

  • falls vorhanden: Datei-/Ordner-Freigaben

  • Zugewiesene Netzwerkverbindung

Was Bodhi angeht: Ein Blick in die Logdateien, speziell das journal (falls das systemd verwendet) wäre hilfreich, um zu wissen, wo es stockt.

Falls du dann ein etwas konkreteres Problem hast, können wir dir vielleicht besser helfen.

Rosika

(Themenstarter)

Anmeldungsdatum:
26. Februar 2016

Beiträge: 1359

@ChickenLipsRfun2eat:

Hallo und vielen Dank für Deine ausführliche Antwort,

ich versuche, die Log-Dateien auszuwerten, um zu sehen, ob ich da etwas finde. Als erstes poste ich mal, was ich bzgl. des efreet-errors gefunden habe:

cat /var/log/syslog | grep efreet
Dec 13 17:53:45 rosika2-Standard-PC-i440FX-PIIX-1996 systemd[1]: session-c2.scope: Killing process 964 (efreetd) with signal SIGTERM.
Dec 13 18:11:08 rosika2-Standard-PC-i440FX-PIIX-1996 systemd[1]: session-c2.scope: Killing process 844 (efreetd) with signal SIGTERM.
Dec 15 14:45:16 rosika2-Standard-PC-i440FX-PIIX-1996 systemd[1]: session-c2.scope: Killing process 918 (efreetd) with signal SIGTERM.
Dec 15 15:14:40 rosika2-Standard-PC-i440FX-PIIX-1996 systemd[1]: session-c2.scope: Killing process 840 (efreetd) with signal SIGTERM.
Dec 31 14:17:30 rosika2-Standard-PC-i440FX-PIIX-1996 dbus-daemon[1235]: [session uid=1000 pid=1235] Activating service name='ca.desrt.dconf' requested by ':1.61' (uid=1000 pid=1734 comm="gedit /tmp/efreetd_rosika2-Standard-PC-i440FX-PIIX")

Der letzte Eintrag liegt aber ein paar Tage zurück. Danach gings (beim 2.ten Start wieder ohne Probleme). Heute war wieder die efreet-Meldung da (erster Start), aber syslog zeigt nichts an.

Ich habe auch mit systemd-analyze versucht, etwas herauszufinden, was für den langsamen Start verantwortlich sein könnte. Selbst komme ich mit der Interpretation aber nicht weiter. Auf jeden Fall poste ich die Ergebnisse mal hier:

systemd-analyze blame
         47.155s apt-daily.service
         12.137s networkd-dispatcher.service
         11.948s dev-vda1.device
         11.213s snapd.service
          9.988s NetworkManager.service
          7.562s NetworkManager-wait-online.service
          7.505s udisks2.service
          6.972s accounts-daemon.service
          6.882s ModemManager.service
          6.414s systemd-journal-flush.service
          5.386s lightdm.service
          5.383s plymouth-quit-wait.service
          5.017s grub-common.service
          4.010s wpa_supplicant.service
          3.665s avahi-daemon.service
          3.546s ubiquity.service
          3.546s gpu-manager.service
          3.164s systemd-logind.service
          2.633s apport.service
          2.588s rsyslog.service
          1.794s spice-vdagentd.service
          1.754s lm-sensors.service
          1.610s systemd-tmpfiles-setup-dev.service
          1.576s polkit.service
          1.480s pppd-dns.service
          1.435s systemd-udevd.service
          1.344s systemd-sysctl.service
          1.335s lvm2-monitor.service
          1.262s keyboard-setup.service
          1.130s user@1000.service
          1.102s apt-daily-upgrade.service
          1.089s alsa-restore.service
           791ms motd-news.service
           772ms systemd-tmpfiles-setup.service
           642ms systemd-timesyncd.service
           587ms swapfile.swap
           583ms snapd.seeded.service
           462ms systemd-resolved.service
           323ms systemd-random-seed.service
           274ms systemd-journald.service
           266ms console-setup.service
           255ms udisks.service
           171ms hddtemp.service
           147ms dev-mqueue.mount
           145ms sys-kernel-debug.mount
           144ms systemd-remount-fs.service
           138ms ufw.service
           125ms kmod-static-nodes.service
           122ms blk-availability.service
           118ms dev-hugepages.mount
           100ms systemd-modules-load.service
            96ms setvtrgb.service
            91ms systemd-udev-trigger.service
            61ms systemd-update-utmp.service
            46ms rtkit-daemon.service
            29ms plymouth-start.service
            20ms plymouth-read-write.service
            17ms systemd-user-sessions.service
             8ms systemd-update-utmp-runlevel.service
             7ms sys-fs-fuse-connections.mount
             6ms snapd.socket

und

 systemd-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 @32.558s
└─multi-user.target @32.558s
  └─hddtemp.service @32.386s +171ms  #
    └─network-online.target @32.386s
      └─NetworkManager-wait-online.service @24.823s +7.562s  #
        └─NetworkManager.service @14.790s +9.988s  #
          └─dbus.service @12.248s
            └─basic.target @12.245s
              └─sockets.target @12.245s
                └─snapd.socket @12.239s +6ms  #
                  └─sysinit.target @12.117s
                    └─sys-fs-fuse-connections.mount @58.658s +7ms  #
                      └─systemd-modules-load.service @3.902s +100ms  #
                        └─systemd-journald.socket @3.877s
                          └─system.slice @3.877s
                            └─-.slice @3.861s

# sind rote Einträge

Der zweite Start hat wieder ohne Probleme und schneller geklappt:

rosika2@rosika2-Standard-PC-i440FX-PIIX-1996 ~> systemd-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 @24.296s
└─multi-user.target @24.296s
  └─hddtemp.service @22.599s +30ms  #
    └─network-online.target @22.599s
      └─NetworkManager-wait-online.service @20.238s +2.359s  #
        └─NetworkManager.service @14.403s +5.834s  #
          └─dbus.service @9.149s
            └─basic.target @8.864s
              └─sockets.target @8.864s
                └─snapd.socket @8.862s +2ms  #
                  └─sysinit.target @8.740s
                    └─systemd-timesyncd.service @8.409s +330ms  #
                      └─systemd-tmpfiles-setup.service @8.122s +274ms  #
                        └─systemd-journal-flush.service @3.128s +4.992s  #
                          └─systemd-journald.service @2.952s +175ms  #
                            └─systemd-journald-dev-log.socket @2.947s
                              └─system.slice @2.902s
                                └─-.slice @2.885s
rosika2@rosika2-Standard-PC-i440FX-PIIX-1996 ~> systemd-analyze blame         
          11.577s dev-vda1.device
          9.720s networkd-dispatcher.service
          9.198s snapd.service
          9.090s ModemManager.service
          9.031s accounts-daemon.service
          8.631s udisks2.service
          6.784s apport.service
          6.380s grub-common.service
          5.834s NetworkManager.service
          5.759s avahi-daemon.service
          5.598s lm-sensors.service
          5.536s alsa-restore.service
          5.497s systemd-logind.service
          5.489s pppd-dns.service
          5.480s rsyslog.service
          5.399s spice-vdagentd.service
          5.357s gpu-manager.service
          5.291s ubiquity.service
          4.992s systemd-journal-flush.service
          4.020s plymouth-quit-wait.service
          4.013s lightdm.service
          2.359s NetworkManager-wait-online.service
          1.963s polkit.service
          1.383s wpa_supplicant.service
          1.219s systemd-udevd.service
           903ms systemd-tmpfiles-setup-dev.service
           500ms keyboard-setup.service
           362ms systemd-sysctl.service
           330ms systemd-timesyncd.service
           312ms snapd.seeded.service
           274ms systemd-tmpfiles-setup.service
           266ms lvm2-monitor.service
           249ms systemd-resolved.service
           217ms systemd-udev-trigger.service
           186ms systemd-modules-load.service
           176ms swapfile.swap
           175ms systemd-journald.service
           162ms console-setup.service
           158ms setvtrgb.service
           131ms ufw.service
           111ms user@1000.service
            90ms systemd-random-seed.service
            88ms sys-kernel-debug.mount
            87ms blk-availability.service
            86ms systemd-update-utmp.service
            79ms systemd-remount-fs.service
            63ms udisks.service
            49ms rtkit-daemon.service
            37ms dev-hugepages.mount
            36ms dev-mqueue.mount
            36ms kmod-static-nodes.service
            30ms hddtemp.service
            26ms systemd-user-sessions.service
            24ms plymouth-start.service
            21ms plymouth-read-write.service
            19ms systemd-update-utmp-runlevel.service
             6ms sys-fs-fuse-connections.mount
             2ms snapd.socket

Was weitere Infos anbelangt, sehe ich nach, was ich herausfinden kann und melde mich wieder.

Einstweilen vielen Dank.

LG. Rosika ☺

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Erscheint mir auch sehr langsam. Welche Hardware hat denn der Host und wieviel davon darf die VM nutzen? Evtl. ist da weniger mehr.

Falls du nicht auf den NetworkManager angewiesen bist, würde ich dir schon mal die Netzwerk-Konfiguration über systemd-networkd empfehlen. Da sparst du einiges an Zeit und die VM hat ja eh eine "stabile Kabelverbindung".

Mal zum Vergleich gekürzte Ausgaben von hier (je 2 Kerne, 4GB RAM zugewiesen ): Arch-Client:

[user@av ~]$ systemd-analyze blame
407ms systemd-logind.service            
359ms dev-vda1.device                   
220ms systemd-resolved.service          
208ms systemd-udevd.service             
197ms systemd-networkd.service          
191ms systemd-journald.service          
 86ms systemd-journal-flush.service     
 53ms systemd-udev-trigger.service      
 52ms …

Ubuntu-Server-Client:

2.789s postgresql@11-main.service               
2.785s postgresql@12-main.service               
2.628s mysql.service                            
2.218s e2scrub_reap.service                     
1.933s systemd-networkd-wait-online.service     
 944ms systemd-logind.service                   
 935ms dev-mapper-usrv2\x2d\x2dvg\x2droot.device
 605ms systemd-resolved.service                 
 406ms systemd-networkd.service                 
 400ms systemd-journald.service                 
 395ms systemd-timesyncd.service                
 257ms postfix@-.service                        
 250ms phpsessionclean.service                  
 216ms networkd-dispatcher.service              
 165ms grub-initrd-fallback.service             
 155ms apache2.service                          
 151ms keyboard-setup.service                   
 150ms grub-common.service                      
 119ms nginx.service                            
 114ms systemd-random-seed.service              
 111ms lvm2-monitor.service                     
 102ms accounts-daemon.service                  
  82ms …

Da das so langsam ist: Hast du die Virtualisierung denn im UEFI aktiviert und wird die VM auch mit kvm gestartet?

Rosika

(Themenstarter)

Anmeldungsdatum:
26. Februar 2016

Beiträge: 1359

@ChickenLipsRfun2eat:

Danke für die neue Info.

Ich habe zuerst einmal folgendes getan:

Nach dem Vergleich der beiden systemd-analyze blame Meldungen von gestern fiel mir auf, daß beim zweiten Mal (jener boot ohne besagte efreet-Meldung) der Eintrag apt-daily.service fehlte. Daraufhin habe ich in Bodhi mit "software-properties-gtk" bei "Updates" "Automatically check for updates" auf "Never" gesetzt.

Als ich heute Bodhi startete, sah systemd-analyze blame so aus:

12.277s networkd-dispatcher.service
         11.021s accounts-daemon.service
         10.163s udisks2.service
          9.538s dev-vda1.device
          9.187s apt-daily.service
          9.160s systemd-journal-flush.service
          8.945s snapd.service
          8.159s NetworkManager.service
          7.108s grub-common.service
          6.622s apport.service
          6.240s ModemManager.service
          5.685s spice-vdagentd.service
          5.507s avahi-daemon.service
          5.497s NetworkManager-wait-online.service
          5.295s alsa-restore.service
          5.268s gpu-manager.service
          5.263s ubiquity.service
[...]

Der zeitintesivste erste Eintrag ("apt-daily.service") war wesentlich niedriger. Ich dachte, vielleicht lag´s daran; aber leider kam die efreet-Meldung dennoch.

Zu meiner Hardware:

PC: Lenovo-H520e
CPU: Intel Core i3-3240T @ 2.900GHz
Speicher: 4 GB

VM:

zugewiesener Speicher: 1 GB
Hypervisor: KVM
Architektur: x86_64
Emulator: /usr/bin/kvm-spice
Firmware: BIOS
Chipsatz: i440FX
CPU-Modell: IvyBridge-IBRS

Falls du nicht auf den NetworkManager angewiesen bist, würde ich dir schon mal die Netzwerk-Konfiguration über systemd-networkd empfehlen.

Habe mir den Link durchgesehen, bin mir aber nicht ganz sicher, was genau Du mir vorschlägst. Was könnte ich ändern ❓

wird die VM auch mit kvm gestartet?

Ja, ich denke schon.

Ich habe ein zweites - älteres - Bodhi (xenial) auch in einer VM laufen, nämlich mithilfe von VMWare Workstation (VMware Player 15.1.0 build-13591040). Dort ist die efreet-Meldung nie aufgetreten.

LG. Rosika

Antworten |