langsamer Start - A start job is running for dev-sda1.device

  • Mein Rootserver startet seit einiger Zeit etwas langsam, weil systemd immer 1:30 Minuten lang versucht, den o.g. Dienst zu starten.


    Anscheinend versucht er, /dev/sda1 (meine swap-Partition) zu finden. Ich glaube mich erinnern zu können, dass früher die Platten bei den Rootservern unter sdX zu finden waren, seit einiger Zeit sind sie jedoch wie bei den vServern unter vdX.

    Auswirkungen auf den normalen Betrieb hat es keine, die swap-Partition wird dennoch gefunden und eingebunden.


    Wie kann ich dieses Überbleibsel finden und entfernen, damit der Start nicht immer so lange dauert?


    Code: cat /etc/fstab
    UUID=bd35d12b-7bf2-4b20-8cf7-ec717cbd6e73 swap                 swap       defaults              0 0
    UUID=89cecee8-c0e1-4063-847e-2093570f817d /                    ext4       acl,user_xattr        1 1
    
    #ramdisk
    tmpfs  /ramdisk  tmpfs  defaults,size=4G  0  0
    Code: lsblk -f
    NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
    sr0                                                      
    vda                                                      
    ├─vda1 swap         bd35d12b-7bf2-4b20-8cf7-ec717cbd6e73 [SWAP]
    └─vda2 ext4         89cecee8-c0e1-4063-847e-2093570f817d /

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Der Unterschied zwischen sdX und vdX kommt vom eingestellten HDD-Treiber im SCP. Was hast Du dort konfiguriert? Normalerweise hat man bei sdX mehr Vorteile, weil z.B. fstrim/discard genutzt werden kann.


    Was sagt ein systemctl status dev-sda1.service? Normalerweise sollte es für diesen Service irgendwo eine Datei in /etc/systemd oder /lib/systemd geben.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Code
    # systemctl status dev-sda1.device
    ● dev-sda1.device
       Loaded: loaded
       Active: inactive (dead)

    Aber ich finde es nirgends im System.


    Ich glaube, ich habe das System mit dem SCSI-Treiber installiert und dann auf VIRTIO gewechselt, also war ich selbst schuld.

    Warum wird der SCSI-Treiber empfohlen? Ist VIRTIO nicht normalerweise schneller als wenn Hardware emuliert wird?


    Habe mal versuchsweise auf SCSI umgestellt und es bootet tatsächlich um einiges schneller.

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Ehrlich gesagt bin ich gerade überfragt, woher Systemd diese veraltete Information bekommt. Ich blicke bei Systemd aber auch nicht überall durch. Ein rekursives grep bringt auch keine neuen Erkenntnisse?


    Welches Betriebssystem und Version ist das? Normalerweise sollte der Swap trotzdem durch die fstab gemountet werden. Versuch mal diesen Service zu deaktivieren: systemctl disable dev-sda1.service

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • openSUSE Tumbleweed mit dem neuesten Snapshot (20181122).


    Deaktivieren kann ich es nicht, weil systemd unter diesem Namen nichts findet (dev-sda1.device), auch dev-sda1.service ist ihm unbekannt.

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Sorry, dass ich Dir bei Deinem ursprünglichen Problem nicht weiter helfen kann. Ich habe keine Ahnung, wo Systemd diese alte Information her haben könnte. Da muss ich passen, vor allem da ich mich mit den Besonderheiten von openSUSE nicht auskenne.

    Technisch korrekt wäre ja "VIRTIO" = virtio-blk und "SCSI" = virtio-scsi, oder?

    Ja, müsste so sein, wenn ich das richtig im Kopf habe.


    Diese Bezeichnungen sind allerdings durchaus üblich, wie sie netcup im SCP verwendet:


    Bildschirmfoto_2018-11-26_00-14-00.png


    (Screenshot von virt-manager)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Eine Anmerkung zum verwendeten Festplatten-Treiber: VIRTIO unterstützt kein fstrim/discard, mit der Zeit wird dir also deine virtuelle Platte auf dem Host volllaufen und du wirst keine Snapshots mehr machen können. SCSI ist wie oben schon erwähnt eigentlich "virtio-scsi", also ebenfalls VIRTIO. Hat also keine Nach-, sondern nur Vorteile und wird daher empfohlen :)

  • Okay, alles klar! Dann ist die Bezeichnung "SCSI" ja wirklich etwas irreführend, weil man glauben könnte es wäre eine simple Hardware-Emulation wie SATA oder IDE...

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Das hat eher einen anderen Hintergrund: Bei SCSI ist der Bustyp gemeint. Dabei wird ein SCSI-Controller emuliert, der wiederum über VirtIO läuft. Bei VIRTIO hingegen läuft es quasi ohne extra Controller bzw. über den Bus VirtIO. Da wird die virtuelle Festplatte quasi direkt angesprochen. (Laienhaft ausgedrückt.)


    Wenn man sich ansieht, wie bei QEMU/KVM das Gerät (die Disk) definiert wird, erscheinen die Bezeichnungen absolut logisch. Sofern man beim unverständlichen QEMU/KVM Parameter Murks von logisch sprechen kann… ^^

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Die richtige Einstellung in KVM, wie einige von Euch schon festgestellt haben ist nicht Virtio (das liefert die vdX-Devices und kann kein trim), sondern SCSI mit dem Submodell SCSI-Virtio. Damit hat Euer Gastsystem eine SCSI-Schnittstelle zur Verfügung, das der Hypervisior mittels virtio an den Treiber des Hosts weiterreicht. Das sollte auch von der Performance her ideal sein.

  • Wie kann ich dieses Überbleibsel finden und entfernen, damit der Start nicht immer so lange dauert?

    swapon -s würde die aktivierten Swaps nach ihrem Devicenamen anzeigen.

    SuSE hab ich vor Jahren aufgegeben. Ich könnte mir aber vorstellen, dass das Service unter /lib/systemd/system/sysinit.target.wants/dev-* liegt.

    find /lib/systemd/ -name "*dev-*"


    Außerdem würde ich mit

    systemctl --state=failed

    schauen, ob nicht noch ein Service hängt.


    Ein wenig off-topic zur Swap-Problematik an sich:
    Ich habe mir unter Debian eine /etc/systemd/system/zram-swap.service angelegt. Die hat folgenden Inhalt:


    Den Tip habe ich irgendwo ergoogelt, es ist nicht auf meinem Mist gewachsen. Zusätzlich musste ich das Modul zram laden. Was macht mir das?


    Auf einem Multicore-Server mit ausreichendem, aber begrenztem Speicher nehme ich 500MB vom RAM und lasse vom Kernel komprimieren. Die so entstandene im Zugriff priorisierte Ramdisk entlastet unter der Annahme, dass die CPUs nicht immer ausgelastet sind so das System von den in der Latenz größeren Schreibzugriffen auf die Platte. Zusätzlich gibt es die herkömmlichen Swappartition. Auf embedded Systems wie OpenWRT kann man das auch machen, aber da sehe ich öfter korrumpierte Speicherbereiche - es arbeitet auf MIPS-Architekturen nicht so wirklich gut. Bei einer Ein-CPU-Maschine geht das von der Performance eher nach Hinten los. Bei Root-Servern mit zwei dedizierten Kernen und SATA-Platte kann eventuell mal darüber nachdenken. Auch bei Systemen mit SSD halte ich es für sinnvoll, weil Schreibzugriffe eher begrenzend auf die Lebensdauer derselben wirken. Wenn man lustig ist, verzichtet man auf die dedizierte Swap-Partition und nimmt dynamischen Swap mittels swapspace. Aber bitte nicht von und auf der / Partition (!).

  • Ich glaube ich habe den Fehler nun gefunden:


    GRUB hat eine config-Datei in /etc/default/grub, mit welcher die /boot/grub2/grub.cfg erstellt wird. In dieser /etc/default/grub steht folgende Zeile:

    Code
    GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"


    "resume", also von welcher Partition bei einem suspend-to-disk gestartet wird. Dieser Partitionsname kann sich aber durch einen Hardwarewechsel ändern, entweder durch Umstellen im SCP oder wie ich es gerade erlebt habe, durch einen Hardwarewechsel (Klonen auf andere SSD). Allerdings wird diese Variable nicht automatisch aktualisert, sondern das muss man selbst machen, sonst versucht systemd beim Starten vergeblich, diese Partition zu finden bis es entnervt aufgibt (1m30s standardmäßig hier) ^^


    Nachdem ich diese Zeile auf meinem PC angepasst habe, gibts keine Probleme mehr beim Start. Ich bin sicher, dass es sich mit den VPS gleich verhält.

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Weil es gerade dazu passt: Ich lief gestern in ein ähnliches Problem. Der Systemstart dauerte immer 30-60 Sekunden, weil er auf die nicht mehr existente Swap-Partition für ein "Resume" wartete. Die hatte ich zuvor aber gelöscht, da ich sie doch nicht brauche.


    Die Lösung unter Debian (10): Einfach mal einen Blick in die Datei /etc/initramfs-tools/conf.d/resume werfen. Siehe: https://lists.debian.org/debian-user/2017/09/msg00866.html

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)