ModemManager und die Bootzeit

[scientific]

Hi Leute!

Nachdem die Bootzeit von meinem Laptop mal wieder massiv lang war, hab ich mich jetzt in einer freien Minute mal wieder dem Thema gewidmet.

Und ich habe festgestellt, dass ModemManager.service die Bootzeit des Systems extrem verlängert. Mit extrem meine ich von 10 Sekunden ohne ModemManager auf fast 30 Sekunden mit...

Ein systemctl disable ModemManger war nicht ausreichend, er wurde trotzdem aufgrund von Abhängigkeiten gestartet.
Erst ein systemctl mask ModemManager legte diesen dann vollkommen lahm und reduzierte die Bootzeit auf 10 Sekunden bzw.

Code: Alles auswählen

# 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 @4.130s
└─multi-user.target @4.130s
  └─NetworkManager.service @2.389s +1.741s
    └─basic.target @2.383s
      └─sockets.target @2.383s
        └─dbus.socket @2.383s
          └─sysinit.target @2.377s
            └─systemd-journald.service @3.735s
              └─systemd-journald.socket @2.381s
                └─-.slice @283ms

unter 5 Sekunden ab Start von systemd.

Momentan betreibe ich kein UMTS-Modem, daher ist dieser Dienst auch nicht wirklich notwendig. Aber ich plane schon in absehbarer Zeit ev. wieder meinen UMTS-Stick in Betrieb zu nehmen... Dann benötige ich den ModemManager wieder.

Warum braucht dieses Teil eigentlich so derart lange um betriebsbereit zu sein, und warum verzögert der den Start von ufw, iptables, avahi.service usw...
Und gibt es schon irgend eine Lösung, dass der ev. erst beim Plugin eines UMTS-Modems oder 4G-Modems angeworfen wird? Udev?

lg scientific

[tomi89]

Probier mal die Schnittstelle (ppp0, usb0 oder was es auch immer sein mag) in der Datei /etc/default/networking zu excluden:

Code: Alles auswählen

EXCLUDE_INTERFACES=ppp0

[scientific]

Die Bootzeit variiert immer wieder ganz massiv...

Eine Fehlerursache habe ich schon rausgefunden. Sie liegt an btrfs. Ich mache jetzt täglich ein btrfs-balance. Seitdem sind die Bootzeiten deutlich kürzer.
Eine weitere Quelle der Verzögerung war der ntpd. Diesen habe ich durch systemd-timesyncd ersetzt.

Der Modemmanager ist momentan maskiert (also Symlink auf /dev/null).

Jetzt sind die Bootzeiten erträglich.

Was ich aber nicht verstehe... Bei den Bootmeldungen sehe ich, dass gdm.service bereits gestartet ist, aber die Oberfläche von gdm lässt auf sich warten. Was kann der Grund dafür sein? Worauf wartet gdm noch? Und vor allem, wie finde ich heraus, worauf gdm wartet, bis es sich "zeigt"?


lg scientific

[trg2889]

Nur mal so am rande ohne Verbindung zum Internet probiert ntpd verschiedene zeitserver aus bis er einen gefunden hat oder von alleine aufgibt das hemmt gewaltig und mit Verbindung zum Modemmanager sowieso wenn dies die einzige Verbindung zum Internet ist.

[scientific]

Nur mal so am rande ohne Verbindung zum Internet probiert ntpd verschiedene zeitserver aus bis er einen gefunden hat oder von alleine aufgibt das hemmt gewaltig und mit Verbindung zum Modemmanager sowieso wenn dies die einzige Verbindung zum Internet ist.

Ja da bin ich auch erst durch Zufall draufgekommen...
Jetzt mit systemd-timesyncd geht es viel flotter.

[ThorstenS]

und so funktionierts:

Code: Alles auswählen

systemctl enable systemd-timesyncd
systemctl restart systemd-timesyncd.service 
systemctl status systemd-timesyncd

alternative Zeitserver können in der /etc/systemd/timesyncd.conf eingetragen werden.

[scientific]

Hab jetzt noch eine spannende Entdeckung gemacht...

Hab für exim - das lokal am Laptop läuft - die Socket-Activation mit systemd erfolgreich* gebaut. Jetzt ist die Zeit von der Meldung, dass gdm gestartet wurde bis tatsächlich die GDM-Oberfläche erscheint signifikant gesunken.

* fetchmail ruft noch zu oft exim auf... da muss ich mir noch etwas überlegen.

lg scientific

[ThorstenS]

und wie hast du das gemacht?

[scientific]

Ich hab mich an diese Anleitung gehalten https://gist.github.com/grawity/9fb7d5af5ae3d80ef62b

Achtung, bei Debian liegt exim/exim4 in /usr/sbin und nicht wie in der Anleitung in /usr/bin! Darüber bin ich zuerst gestolpert.

Ich hab dann diese Dienste aktiviert (aus der Anleitung am Ende)

Socket-activated mode

enable exim@smtp.socket and/or exim@submission.socket
enable exim-queue.path and/or exim-queue.timer

und exim4.service disabled, bwz. maskiert (=link auf /dev/null)

Wie ich aber schon schrieb, klappt es mit fetchmail noch nicht ganz. Da beschwert sich systemd, dass exim-queue.service zu oft aufgerufen wird. Das muss ich noch lösen.
Ev. mach ich das mit einer Abfrage im Service-File, ob es schon läuft.

lg scientific

[scientific]

Neueste Beobachtung:

Hab cups und noch ein paar andere daemons (leafnode z.b. und exim4) auf socket-activation umgestellt. inetd entfernt und mit systemd-units zusammengebaut, die es in debian noch nicht gibt.

wenn ein netzwerk erreichbar ist, ist die bootzeit nun <20 Sekunden.
Ohne Netzwerk läufts auf ein Timeout hinaus, bis gdm mich einloggen lässt.

ob ich das auch noch hinkriegen werd?

nun jedenfalls taugt mir die socket-activation und systemd schon sehr.

Lg scientific