• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Opensuse 13.1 - langsamer Systemstart mit ifup

panamajo

panamajo

Guru
Auf einem Rechner mit openSUSE 13.1 wurden lt. systemd-analyze blame immer ca. 30s beim Start des NFS Clients verbraten. Beim Start kam immer 5x abwechselnd "Link is up", "Link is down".
Bis ich merkte dass die Netzwerkkarte nur mit 100 MBit unterwegs war, obwohl GBit fähig (sowohl die Karte als auch der Switch auf der Gegenseite), lag am falschen Kabel.
Gegen CAT6 ausgetauscht, und siehe da:
Code: 
# systemd-analyze blame
          6.793s network.service
          6.084s network@eth0.service
          1.398s ntp.service
           762ms nfs.service
Damit kann ich leben...
Ich vermute mal dass openSUSE 13.1 per ethtool rausfindet welches Potential eine Netzwerkverbindung hätte und versucht das Optimum zu erreichen.
 
A

admine

Ultimate Guru
Jägerschlürfer schrieb:
deaktiviere den ntp Dienst doch bitte einmal,...
Zum Vergrößern anklicken....
Hab ich eben mal gemacht ... und ja, gefühlt startet das Laptop jetzt schneller, nur ohne ntpd is auch doof ;)
Ich nehm die paar Sekunden in Kauf.
 
spezi

spezi

Advanced Hacker
Hallo,
ich habe auch diese Wartezeit beim booten und ifup. In der /etc/sysconfig/network/dhcp gibt es den Eintrag DHCLIENT_WAIT_AT_BOOT mit default 15 sec. Eine Anderung verhindert die Wartezeit.
Ich habe das jetzt mal bis auf "0" gestellt und noch nichts böses bemerkt.

Das kam bei systemd-analyze blame raus

Code: 
Original 15 sec
	  17.311s network.service
         16.924s network@eth0.service
            
Start mit 5 sec       
         6.544s network.service
          6.172s network@eth0.service

Start mit 0 sec
	  1.027s network.service
           653ms network@eth0.service
           
und wieder zurück auf default (15sec)

         17.192s network.service
         16.790s network@eth0.service

Ich werde das nochmal beobachten.

mfg
spezi
 
panamajo

panamajo

Guru
spezi schrieb:
ich habe auch diese Wartezeit beim booten und ifup. In der /etc/sysconfig/network/dhcp gibt es den Eintrag DHCLIENT_WAIT_AT_BOOT mit default 15 sec. Eine Anderung verhindert die Wartezeit.
Ich habe das jetzt mal bis auf "0" gestellt und noch nichts böses bemerkt.
Zum Vergrößern anklicken....

Ja. Obwohl in der Datei ganz klar steht dass der Wert ein Maximum darstellt:
Code: 
# When the DHCP client is started at boot time, the boot process will stop
# until the interface is successfully configured, but at most for
# DHCLIENT_WAIT_AT_BOOT seconds.

Tatsächlich wirkt sich eine Änderung bei openSUSE 13.1 direkt auf die Zeit aus die für den Network Service verbraten wird - also Pustekuchen mit "at most"
 
spezi

spezi

Advanced Hacker
Hallo,
#...Das stehr auch noch da
Code: 
Do not set this variable higher than the
# WAIT_FOR_INTERFACES variable -- it is adjusted to WAIT_FOR_INTERFACES/2
# as default.
deswegen werde ich das noch etwas beobachten. Aber wo, in welcher Datei, ist dieses "WAIT_FOR_INTERFACES"?

mfg
spezi
 
harley

harley

Hacker
WAIT_FOR_INTERFACES ist unter Network/General zu finden. Der Wert steht bei mir auf 30s.

Michael :-D
 
spezi

spezi

Advanced Hacker
Hallo,
ich habe den WAIT_FOR_INTERFACES mal leer gemacht, neugestartet und keine Auswirkungen bemerkt. Das ist sicher nur für sehr exotische Hardware, die diese Zeit braucht, gedacht.
Code: 
ystemd-analyze blame
          2.318s hddtemp.service
          1.903s lvm2-activation-early.service
          1.256s cycle.service
          1.254s systemd-udev-root-symlink.service
          1.128s home.mount
          1.113s network.service
      --schnipp--

So sieht das bis jetzt bei mir aus.

mfg
spezi
 
OP
M

mojo

Member
Ich habe die Ursache (zumindest bei mir) gefunden!!!

Hintergrund: ich habe Opensuse 13.1 komplett neu installiert (in der alten Installation hatte sich zuviel "Gerümpel" angesammelt).
Der Systemstart klappte dank SSD nun wieder blitzschnell. Und das, obwohl das Setup die Netzwerkkarte wieder mit "ifup" anstatt dem "NetworkManager" konfigurierte.

Als ich das System so nach und nach wieder an meine Bedürfnisse angepasst habe, habe ich u.a. auch mit Yast die Einstellung der Systemzeit von "manuell" (default nach Neuinstallation) auf "Mit NTP-Server synchronisieren" gestellt.

Und siehe da: beim nächsten Systemstart legte Opensuse wieder eine Gedenkpause beim initialisieren der Netzwerkkarte ein.

Die Einstellung für die Systemzeit wieder zurück auf "manuell" gestellt und Suse startet wieder flott durch.

Das ganze habe ich noch ein paarmal gemacht und konnte das Ergebnis immer wieder verifizieren!

Ergebnis: der langsame Systemstart mittels "ifup" tritt dann auf, wenn die Zeitsynchronisation durch einen NTP-Server erfolgt.


mojo
 
OP
M

mojo

Member
Jägerschlürfer schrieb:
Danke mojo für die Rückinfo.

Ist es hierbei egal, um welchen NTP-Server es sich hierbei handelt?
Zum Vergrößern anklicken....
Augenscheinlich ja.

Sobald ich die Zeitsynchronisation von "manuell" auf "Mit NTP-Server synchronisieren" stelle, wird beim booten pausiert. Unabhängig davon, welcher NTP-Server eingetragen ist.


mojo
 
X

XXL1

Newbie
Falls hier noch probleme bestehen: Bei mir hat der avahi daemon zu ~15sec Verzögerung pro Interface geführt. Nachdem ich die avahi scripte testweise aus "/etc/sysconfig/network/if-up.d" entfernt habe braucht ein Interface ~220ms. Hab auch noch keine negativen Folgen bemerkt.
 
OP
M

mojo

Member
Ich habe dies die Tage noch einmal verifizieren können.

Neuinstallation von Opensuse 13.1 auf einem Dell Optiplex (Intel Core2 Duo 2,33 MHz).
Sobald ich die Zeitsynchronisation via NTP aktiviert habe, dauert der Bootvorgang gut 25 Sekunden länger (festgestellt mittels "sytemd-analyze blame").

Durch Verringerung des Wertes in der /etc/sysconfig/network/dhcp bei DHCLIENT_WAIT_AT_BOOT konnte ich die Wartezeit analog reduzieren. Den Wert auf Null setzen wollte ich nicht, da ich nicht weiß ob dadurch anderweitige Probleme entstehen (können). Und da der Rechner nicht bei mir steht, wollte ich vermeiden, da wegen Problemen event. wieder hinfahren zu müssen.

Aber erst die Verwendung des Network-Managers anstatt ifup hat die "Gedenkminute" auf nahezu null reduziert.


mojo
 
OP
M

mojo

Member
Hab eben nochmal umgestellt:
Problem besteht immer noch!

Linux:/home/test # systemd-analyze blame
9.474s network.service
9.211s network@eno1.service
162ms SuSEfirewall2_init.service
136ms postfix.service
124ms ModemManager.service
117ms apparmor.service
94ms rsyslog.service
93ms lm_sensors.service
Zum Vergrößern anklicken....

Ich hatte eigentlich gehofft, dass die zwischenzeitlich erfolgten Updates das Problem gelöst hätten.
So bleibt weiterhin nur entweder den Networkmanager zu nutzen oder die Zeitsynchronisation mittels NTP zu deaktivieren.


mojo
 
gehrke

gehrke

Administrator
Teammitglied
mojo schrieb:
Ich hatte eigentlich gehofft, dass die zwischenzeitlich erfolgten Updates das Problem gelöst hätten.
So bleibt weiterhin nur entweder den Networkmanager zu nutzen oder die Zeitsynchronisation mittels NTP zu deaktivieren.
Zum Vergrößern anklicken....
Bist Du sicher? Ich habe jetzt nicht jedes Detail Deines Problems nachvollzogen, aber diesen Thread hier als Muster für mein eigenes Problem verwendet und bin zu einer zufriedenstellenden Lösung gekommen. Vielleicht hilft es Dir, wenn Du meinen Beitrag hier vom 14. Mär 2014, 22:17 noch mal ansiehst.

Ich könnte mir vorstellen, dass es auch in Deinem Fall nicht an ntp direkt liegt, sondern an DHCP (wodurch ja erst die Voraussetzung geschaffen wird, dass ntp als Netzwerk-Protokoll funktionieren kann).
 
OP
M

mojo

Member
gehrke schrieb:
Bist Du sicher?
Zum Vergrößern anklicken....
Eigentlich schon.
Siehe oben meine Ausgabe von "systemd-analyze blame".

gehrke schrieb:
Ich könnte mir vorstellen, dass es auch in Deinem Fall nicht an ntp direkt liegt, sondern an DHCP (wodurch ja erst die Voraussetzung geschaffen wird, dass ntp als Netzwerk-Protokoll funktionieren kann).
Zum Vergrößern anklicken....
Das ist richtig.

Dagegen spricht aber, dass "DHCP" einwandfrei funktioniert, wenn "ntp" deaktiviert ist.
Und "DHCP" und "ntp" funktionieren zusammen auch, wenn "Networkmanager" anstatt "ifup" verwendet wird.

Auch habe ich das Problem durchgehend auf allen meinen Installationen von Opensuse 13.1.
Einzige Gemeinsamkeit ist, dass alle PC Intel-Prozessoren haben, wenn auch unterschiedliche (SU4100, C2D 6300, i3-4130, i5-2500k).


mojoh
 
gehrke

gehrke

Administrator
Teammitglied
mojo schrieb:
Durch Verringerung des Wertes in der /etc/sysconfig/network/dhcp bei DHCLIENT_WAIT_AT_BOOT konnte ich die Wartezeit analog reduzieren. Den Wert auf Null setzen wollte ich nicht, da ich nicht weiß ob dadurch anderweitige Probleme entstehen (können). Und da der Rechner nicht bei mir steht, wollte ich vermeiden, da wegen Problemen event. wieder hinfahren zu müssen.
Zum Vergrößern anklicken....
mojo schrieb:
Auch habe ich das Problem durchgehend auf allen meinen Installationen von Opensuse 13.1.
Zum Vergrößern anklicken....
Und da ist keiner dabei, bei dem Du mal testen könntest, welche Auswirkungen die Zeile
Code: 
DHCLIENT_WAIT_AT_BOOT="0"
wirklich hat?

Meine Änderung brachte bislang tatsächlich noch nichts negatives hervor, außer die Sache mit NFS/Automount.
 
F

fabramowski

Newbie
Hatte das gleiche wie alle hier, 17 s network.service, habe dan mal den WLAN USB stick rausgenommen. Das wars. Nu steht da 3 s

MfG
Frank
 
OP
M

mojo

Member
Ich will nochmal den alten Thread hochholen, denn das Problem besteht bei Opensuse 13.2 immer noch.

Sobald NTP aktiviert ist, braucht der wicked.service zwischen 23 und 30 Sekunden.

Die Verringerung von DHCLIENT_WAIT_AT_BOOT_TIME hat leider nix gebracht.

Das führt im Ergebnis zu dem Kuriosum, dass der Rechner mittels SSD zwar blitzschnell startet und die Oberfläche hochgefahren ist, aber ich bis zur Benutzung noch etliche Zeit warten muss bis dann endlich auch das Netzwerk gestartet ist :nosmile: .


mojo
 
OP
M

mojo

Member
Tja,

und bei Opensuse Leaf 42.1 ist es auch noch so.

Ich habe Leaf komplett neu installiert. Lediglich das /home-Verzeichnis wurde übernommen.

Ist NTP aktiviert und das Netzwerk per Wicked-Dienst initialisiert, dauert der Systemstart wieder ewig.
sysdemd-analyze blame weist dann eindeutig den Netzwerkdienst als den Schuldigen aus.

Wird NTP deaktiviert, startet das System blitzschnell durch.


mojoh
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben