opsiconfd startet nach server reboot nicht ...

[mhaegele]

Hallo!

Wenn der Opsi Server neu gestartet wird startet der opsiconf.d nicht automatisch
wenn man ihn über

Code: Alles auswählen

"/etc/init.d/opsiconfd start"

startet klappt das, ein update hatte auch nicht geholfen
irgendwie scheint er beim start mit mysql ein Problem zu haben:
(11:57 war reboot, 11:59 dann opsiconfd manueller start, dann ok ...)

Code: Alles auswählen

root@domainsopsi1:/var/log/opsi# less opsiconfd/opsiconfd.log
thon2.7/OPSI/Backend/MySQL.py' (Logger.py|754)
[2] [May 05 11:57:01]      line 137 in '__init__' in file '/usr/lib/pymodules/py
thon2.7/OPSI/Backend/MySQL.py' (Logger.py|754)
[2] [May 05 11:57:01]      line 164 in '_createConnectionPool' in file '/usr/lib
/pymodules/python2.7/OPSI/Backend/MySQL.py' (Logger.py|754)
[2] [May 05 11:57:01]      ==>>> Backend I/O error: Failed to connect to databas
e 'opsi' address 'localhost': (2002, "Can't connect to local MySQL server throug
h socket '/var/run/mysqld/mysqld.sock' (2)") (opsiconfd.py|469)
[5] [May 05 11:57:01] Stopping opsiconfd main thread (opsiconfd.py|175)
[5] [May 05 11:57:01] Opsiconfd main thread exiting... (opsiconfd.py|472)
[1] [May 05 11:59:17]
==================================================================
=             opsi configuration service starting                =
==================================================================
 (Logger.py|840)
[5] [May 05 11:59:19] Starting opsiconfd main thread (opsiconfd.py|447)
[5] [May 05 11:59:19] Opening socket /var/run/opsiconfd/opsiconfd.socket for interprocess communication. (opsiconfd.py|424)
[4] [May 05 11:59:19] Failed to read opsi modules file '/etc/opsi/modules': [Errno 2] No such file or directory: u'/etc/opsi/modules' (Backend.py|365)
[5] [May 05 11:59:19] Disabling mysql backend and license management module: no customer in modules file (MySQL.py|435)

Jemand ne Idee?
Danke Vorab!
MH

[ueluekmen]

Hi,

das ist ein known Bug. Welches OS setzt du ein auf dem opsi-Server?

[dkoch]

Code: Alles auswählen

echo "/etc/init.d/opsiconfd start" >> /etc/rc.local

Das sollte fürs erste Abhilfe schaffen auch wenn es nicht die eleganteste Lösung ist.

[ueluekmen]

Hallo koch,

das löst nicht das Problem. Das Problem hier ist, dass der mysql-server noch nicht gestartet wurde, bevor der opsiconfd startet. Das haben wir alles upstart und co zu verdanken. Es gibt Lösungswege dazu, aber um in diesem speziellen Fall eine Lösung zu posten, muss man wissen, welches System hier betroffen ist. Weil natürlich jedes System auch wieder seine eigene Lösung verlangt.

Im übrigen hatten wir dieses Thema schon in einigen anderen Threads, da findet man dann auch datailiertere Informationen, wenn man über die Forumsuche mal danach sucht.

[dkoch]

Hallo koch,

das löst nicht das Problem.

rc.local wird recht spät ausgeführt (Requiered-Start: $all). Da läuft mysqld schon.
Das Problem mit der Reihenfolge wird damit nicht gelöst da gebe ich dir recht.
Stattdessen wird opsiconfd in einem 2. versuch gestartet mit der rc.local nachdem mysqld läuft.

[mhaegele]

Hallo!

Danke für die Antworten ...
Ich setze kein Upstart ein ...
Es ist hauptsächlich ein Debian Wheezy mit Backport Kernel 3.11. ...

Ich kenn mich da unter linux leider in dem Bereich nicht aus aber wäre es nicht möglich dem opsiconfd eine "Zwangspause" zu verordnen bis mysql läuft etc.
bzw. gibt es sowas wie Diensteabhängigkeiten wie unter Windows ...?

Theopraktisch müssten die Opsidienste ja wissen ob Sie lt. Config eine Mysql Instanz benötigen oder nicht ... ?

Vielleicht kann man da ja was machen, bin ja sicher nicht der einzige der das Problem hat?

Code: Alles auswählen

uname -r
3.11-0.bpo.2-686-pae


 cat /etc/apt/sources.list
deb http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb http://ftp.de.debian.org/debian/ wheezy-backports main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy main non-free contrib
deb-src http://ftp.de.debian.org/debian/ wheezy-backports main non-free contrib

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
#sernet samba pakete
deb http://ftp.sernet.de/pub/samba/3.6/debian wheezy main
#deb ftp://ftp.sernet.de/pub/samba/debian/ ./
# wheezy-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy-updates main contrib non-free

#opsi pakete

deb http://download.opensuse.org/repositories/home:/uibmz:/opsi:/opsi40/Debian_7.0 ./

--
 dpkg -l | grep opsi
ii  opsi-atftpd                          0.7.dfsg-2.1                  i386         advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                        4.0.4.1.2-4                   all          OPSI config editor
ii  opsi-depotserver                     4.0.4.4-1                     all          opsi depotserver configuration package
ii  opsi-linux-bootimage                 20140118-1                    all          opsi linux bootimage
ii  opsi-utils                           4.0.4.1-2                     all          opsi utils
ii  opsiconfd                            4.0.4.3-1                     all          opsi configuration service
ii  opsipxeconfd                         4.0.4.1-2                     all          opsi pxe configuration daemon
ii  python-opsi                          4.0.4.5-2                     all          opsi python library

Vielen Dank für die Hilfe
MH

[ueluekmen]

Hallo Koch,

ich hatte bei diesem Problem verschiedene Ansätze mal probiert. Das mit rc.local habe ich auch mal probiert, weil ich das irgendwo in einem Forum aufgeschnappt habe. Das Ergebnis war erst mal positiv, aber bei einigen Systemen ist das auch in die Hose gegangen. Es leben die Standards.

Die beste Möglichkeit, ist das über die LSB-Headers im init-Skript vom opsiconfd zu lösen. Nur da ist die Syntax auch nicht immer die selbe. Dies direkt über das Paket patchen zu lassen, ist auch keine Lösung, da es immernoch opsi-Installationen gibt, die gar kein mysql verwenden. Besonders ganz kleine Installationen verzichten mal gerne auf mysql. Deshalb verfolgen wir momentan den Ansatz bei der daemon-Initialsierung dieses Problem ab zu fangen. Aber das wird, wenn wir es schaffen, in einem der nächsten Releases erscheinen.

[ueluekmen]

Schau mal hier:

viewtopic.php?f=7&t=5791&p=25806&hilit= ... nit#p25806

vereinzelt soll auch im lsb-header:

+mysql

helfen, dies optional zu machen. Aber das + wird leider nicht von jedem System geschluckt, deshalb haben wir diesen Fix nicht veröffentlicht, sondern intern wieder verworfen.