Univention Bugzilla – Bug 17115
Bootvorgang dauert oft sehr lange auf Mobile Clients
Last modified: 2010-03-09 15:20:06 CET
Berichtet an Ticket#2009121710000367 Der Bootvorgang dauert regelmäßig ziemlich lange (>5 Minuten). Das ist sowohl auf UCS 2.2 als auch auf UCS 2.3 Mobile Clientfestgestellt worden. Vermutlicher Grund ist univention-maintenance in Verbindung mit den Paketpflegerichtlinien.
Created attachment 2221 [details] Beispiel bootchart Diagram Konnte ich so bisher auf meinen Testsystemen noch nicht nachstellen. Auffällig sind aber auf jeden Fall die 4 TimeOut-Zeiten von netcat und netdate von jeweils ca 12-26s.
Created attachment 2222 [details] Bootchart-tar für i386 Auspacken nach /: etc/init.d/bootchart etc/bootchartd.conf sbin/bootchartd etc/initramfs-tools/hooks/bootchart etc/rc.local etc//default/acct usr/sbin/accton Quellen: http://ftp.de.debian.org/debian/pool/main/a/acct/acct_6.4~pre1-6_i386.deb http://ftp.de.debian.org/debian/pool/main/b/bootchart/bootchart_0.10~svn407-3.3_all.deb Zum erzeugen des Diagramms: http://ftp.de.debian.org/debian/pool/main/libc/libcommons-cli-java/libcommons-cli-java_1.1-3_all.deb http://ftp.de.debian.org/debian/pool/main/libc/libcommons-compress-java/libcommons-compress-java_0~svn604876-1_all.deb http://ftp.de.debian.org/debian/pool/main/b/bootchart/bootchart-view_0.10~svn407-3.3_all.deb
Created attachment 2231 [details] Bootchart für Fehlerfall Scheint ein DNS-Problem zu sein: Als letztes im Bootvorgang startet der updater ein "apt-get update", wo der 'http'-Downloader dann minutenlang hängt. Janis kann das bestätigen. Reproduzierbar mit /etc/init.d/univention-bind-proxy stop auf dem Master.
Teilweise greifen die univention-updater --check, univention-security-update --check und univention-actualise --check direkt oder indirekt (apt-get, univention-repository-update) auf das Netzwerk zu. Ist beim Starten das Netzwerk nicht erreichbar, kommt es zu der beobachteten Verzögerung. Das init-Skript prüft jetzt am Anfang, ob der LDAP-Server und der Repository-Server (bzw. http-Proxy, siehe Bug #15550) erreichbar sind. (TCP-Verbindung bzw. ping). Wegen Bug #17411 wurde diese Varianten gewählt, daß für die Maintenance immer ein Netzwerk verfügbar sein muß. Ggf. funktionieren deswegen rein lokale Updates nicht mehr, wenn auf dem Repository-Server der LDAP-Server nicht erreichbar ist oder $repository_online_server bzw. $proxy_http nicht ping-bar sind. Getestet in den Varianten: iptables -A OUTPUT -d `ucr get ldap/server/name` -p tcp --dport ldap -j REJECT iptables -A OUTPUT -d `ucr get ldap/server/name` -p tcp --dport ldap -j DROP iptables -A OUTPUT -d `ucr get repository/online/server` -j REJECT iptables -A OUTPUT -d `ucr get repository/online/server` -j DROP ucr set proxy/http=p24.pmhahn24.qa:3128 ; iptables -A OUTPUT -d p24.pmhahn24.qa -j REJECT ucr set proxy/http=p24.pmhahn24.qa:3128 ; iptables -A OUTPUT -d p24.pmhahn24.qa -j DROP
OK, univention-maintenance läuft nur noch, wenn der LDAP Server erreichbar und der Repository-Server bzw. Proxy. Der Repository-Server bzw. Proxy muss dabei auf ein Ping antworten (Achtung bei Firewalls).
UCS 2.3-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".
*** Bug 10543 has been marked as a duplicate of this bug. ***