opsiconfd startet manchmal auf den Depots nicht

[feltel]

Wir haben hier schon seit längerem einen Effekt, der eher nervig ist. Der opsiconfd-Service auf unseren Depotservern startet manchmal nicht automatisch, wenn die Maschinen z.B. wegen eines Kernelupdates neu gestartet werden. Der Effekt ist nicht nachstellbar und tritt eher zufällig mal auf diesem Depot auf und das nächste mal auf jenem. Auffallen tut es, wenn wir neue Pakete auf die Depots schieben und der Package-Builder sie dann nicht hochladen kann. Ein "systemctl start opsiconfd.service" hilft dann immer.

Die Depotserver sind VMs auf ESXI 8. An Software läuft darauf ein Debian 12.10. Der Fehler trat "früher" aber auch schon mal auf, wo die Software noch unter Debian 11 lief. Leider ist der Fehler schwer zu lokalisieren bzw. einzugrenzen, da er mal auftritt und mal nicht. Alles was ich anbieten kann ist die Logausgabe:

Code: Alles auswählen

-- Boot 3accfac1770b4428a91f3cbc330828ff --
Apr 28 09:07:58 bradbury systemd[1]: Starting opsiconfd.service - opsi server daemon...
Apr 28 09:07:59 bradbury systemd[1]: Started opsiconfd.service - opsi server daemon.
Apr 28 09:08:02 bradbury opsiconfd[696]: Traceback (most recent call last):
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/__main__.py", line 28, in main
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/main/__init__.py", line 75, in main
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/main/opsiconfd.py", line 53, in opsiconfd_main
Apr 28 09:08:02 bradbury opsiconfd[696]: RuntimeError: Opsiconfd manager process already running (pid 742)
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Main process exited, code=exited, status=1/FAILURE
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Failed with result 'exit-code'.
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Consumed 2.337s CPU time.

wenn das passiert und was systemctl status sagt:

Code: Alles auswählen

root@bradbury:/home/feltel# systemctl status opsiconfd.service
× opsiconfd.service - opsi server daemon
     Loaded: loaded (/lib/systemd/system/opsiconfd.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-04-28 09:08:03 CEST; 24h ago
   Duration: 4.112s
    Process: 669 ExecStartPre=/usr/lib/opsiconfd/opsiconfd-pre-start (code=exited, status=0/SUCCESS)
    Process: 696 ExecStart=/usr/bin/opsiconfd start --log-level-stderr=0 (code=exited, status=1/FAILURE)
   Main PID: 696 (code=exited, status=1/FAILURE)
        CPU: 2.337s

Apr 28 09:07:58 bradbury systemd[1]: Starting opsiconfd.service - opsi server daemon...
Apr 28 09:07:59 bradbury systemd[1]: Started opsiconfd.service - opsi server daemon.
Apr 28 09:08:02 bradbury opsiconfd[696]: Traceback (most recent call last):
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/__main__.py", line 28, in main
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/main/__init__.py", line 75, in main
Apr 28 09:08:02 bradbury opsiconfd[696]:   File "opsiconfd/main/opsiconfd.py", line 53, in opsiconfd_main
Apr 28 09:08:02 bradbury opsiconfd[696]: RuntimeError: Opsiconfd manager process already running (pid 742)
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Main process exited, code=exited, status=1/FAILURE
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Failed with result 'exit-code'.
Apr 28 09:08:03 bradbury systemd[1]: opsiconfd.service: Consumed 2.337s CPU time.

In /var/log/opsi/opsiconfd/ stehen in den Logfiles leider keine Infos, die zu dem entsprechenden Zeitraum passen. Lediglich ein Paketinstallationsfehler von vor ein paar Wochen.

Alle OPSI-Pakete sind aktuell, aber wie schon geschrieben, den Fehler schleppen wir schon ne Weile mit.

[j.schneider]

Hallo,

das Problem haben wir schon öfter gemeldet bekommen.
In einer der nächsten Versionen geben wir das Kommando des gefundenen Prozesses mit aus.
Das hilft dann wahrscheinlich die Ursache zu finden.

Grüße
Jan Schneider

[j.schneider]

Die Änderung ist in opsiconfd 4.3.31.26.

[feltel]

Danke. Dann werden wir das mal installieren und versuchen den Fehler zu provozieren. Ich geb weiteren Input sobald ich was habe.

[SirTux]

Ich hätte da schon was von unserem Config-Server:

Code: Alles auswählen

Apr 30 09:55:40 opsi systemd[1]: Starting opsiconfd.service - opsi server daemon...
Apr 30 09:55:40 opsi systemd[1]: Started opsiconfd.service - opsi server daemon.
Apr 30 09:55:41 opsi opsiconfd[54895]: Traceback (most recent call last):
Apr 30 09:55:41 opsi opsiconfd[54895]:   File "opsiconfd/__main__.py", line 26, in main
Apr 30 09:55:41 opsi opsiconfd[54895]:   File "opsiconfd/main/__init__.py", line 78, in main
Apr 30 09:55:41 opsi opsiconfd[54895]:   File "opsiconfd/main/opsiconfd.py", line 50, in opsiconfd_main
Apr 30 09:55:41 opsi opsiconfd[54895]: RuntimeError: Opsiconfd manager process already running (pid: 54949, cmdline: /usr/lib/opsiconfd/opsiconfd get-config)
Apr 30 09:55:42 opsi systemd[1]: opsiconfd.service: Main process exited, code=exited, status=1/FAILURE
Apr 30 09:55:42 opsi systemd[1]: opsiconfd.service: Failed with result 'exit-code'.
Apr 30 09:55:42 opsi systemd[1]: opsiconfd.service: Consumed 1.427s CPU time.

[j.schneider]

Vielen Dank, das hilft weiter!

[feltel]

Ja, das "process already running" ist mir initial auch schon aufgefallen.

[j.schneider]

Ich denke, wir konnten das Problem mit opsiconfd 4.3.31.29 lösen.

https://software.opensuse.org//download ... =opsiconfd

[feltel]

Sorry für das späte Feedback. Ich hab die aktualisierte Version vom opsiconfd jetzt mal auf einem Depot eingespielt und die VM ein paar mal neu gestartet. Dabei wäre der Fehler sonst bestimmt mindestens einmal aufgetreten. Jetzt scheint das zum Glück nicht mehr zu passieren. Ich lass das jetzt so und würde die nächsten regulären Updates abwarten, damit der Fix auf den anderen Depots ankommt.

[j.schneider]

Sehr gut, vielen Dank für das Feedback!