opsiconfd - Problem nach Opsi 4.1 Minor Update

[DanschDX]

Sehr geehrtes Opsi Support Forum,

wir sind nach einem Minor Update von Opsi 4.1 auf das Problem gestoßen, dass wir nun den opsiconfd.service nicht mehr starten können und folgende Meldung erscheint:

-- Unit opsiconfd.service has finished shutting down.
May 11 16:08:55 <servername> systemd[1]: Starting Opsi Configuration Service...
-- Subject: Unit opsiconfd.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li ... temd-devel
--
-- Unit opsiconfd.service has begun starting up.
May 11 16:08:55 <servername> python[24940]: detected unhandled Python exception in '/usr/bin/opsiconfd'
May 11 16:08:55 <servername> abrt-server[24947]: Not saving repeating crash in '/usr/bin/opsiconfd'
May 11 16:08:55 <servername> opsiconfd[24940]: Traceback (most recent call last):
May 11 16:08:55 <servername> opsiconfd[24940]: File "/usr/bin/opsiconfd", line 5, in <module>
May 11 16:08:55 <servername> opsiconfd[24940]: from pkg_resources import load_entry_point
May 11 16:08:55 <servername> opsiconfd[24940]: File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 72, in <module>
May 11 16:08:55 <servername> opsiconfd[24940]: File "/usr/lib/python2.7/site-packages/packaging/requirements.py", line 59, in <module>
May 11 16:08:55 <servername> opsiconfd[24940]: TypeError: __call__() takes exactly 2 arguments (1 given)
May 11 16:08:55 <servername> systemd[1]: opsiconfd.service: control process exited, code=exited status=1
May 11 16:08:55 <servername> systemd[1]: Failed to start Opsi Configuration Service.
-- Subject: Unit opsiconfd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li ... temd-devel
--
-- Unit opsiconfd.service has failed.
--
-- The result is failed.
May 11 16:08:55 <servername> systemd[1]: Unit opsiconfd.service entered failed state.
May 11 16:08:55 <servername> systemd[1]: opsiconfd.service failed.


Wir wissen leider nicht genau, wo wir hier anpacken müssen und hoffen Ihr könnt uns hier weiterhelfen.



Mit freundlichen Grüßen

Dansch

[m.radtke]

Hi

Schau doch mal ins Log des opsiconfd

Code: Alles auswählen

/var/log/opsi/opsiconfd/opsiconfd.log

Gruß
Mathias

[DanschDX]

Hi Mathias,

die Logdatei ist leider leer.


Gruß
Dansch

[SisterOfMercy]

Have you tried the default stuff to fix things?

IE:

Code: Alles auswählen

opsi-setup --set-rights
opsi-setup --auto-configure-samba
opsi-setup --init-current-config

[m.radtke]

Starte einfach mal den opsiconfd in der Konsole/Terminal und sieh Dir die Fehlermeldung an.

Gruß
Mathias

[DanschDX]

@SisterofMercy: All of these options lead to the same error message mentioned in the description of this case.

@m.radtke: Dies führt zu der selben Fehlermeldung in verkürzter Form:

Traceback (most recent call last):
File "/bin/opsiconfd", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 72, in <module>
File "/usr/lib/python2.7/site-packages/packaging/requirements.py", line 59, in <module>
TypeError: __call__() takes exactly 2 arguments (1 given)


Gruß
Dansch

[uncle_scrooge]

Welches System? Debian, Ubuntu, CentOS,....

>>Minor Update von Opsi 4.1
Von welcher Version auf welche Version?

[DanschDX]

@uncle_scrooge:
OS: RHEL (Red Hat Enterprise Linux Server) 7.6
Von:
Apr 25 11:54:14 Updated: python-opsi-4.1.1.62-1.1.noarch
Apr 25 11:54:29 Updated: opsi-server-4.1.1.7-1.1.noarch
Apr 25 12:01:31 Updated: opsiconfd-4.1.1.18-4.1.noarch
Apr 25 12:01:59 Updated: opsi-linux-bootimage-20181213-1.1.noarch
Aug 21 19:46:57 Updated: python-opsi-4.1.1.67-1.1.noarch
Aug 21 19:46:57 Updated: opsi-utils-4.1.1.32-2.1.noarch
Aug 21 19:47:21 Updated: opsi-linux-bootimage-20190522-1.1.noarch
Aug 21 19:47:51 Updated: opsi-nagios-plugins-4.1.1.5-1.1.noarch

Auf:
May 06 23:41:08 Updated: python-opsi-4.1.1.86-1.1.noarch
May 06 23:41:08 Updated: opsi-utils-4.1.1.33-6.1.noarch
May 06 23:41:11 Updated: opsi-tftp-hpa-server-5.2.8-51.1.x86_64
May 06 23:41:25 Updated: opsiconfd-4.1.1.20-1.1.noarch
May 06 23:41:40 Updated: opsi-linux-bootimage-20191219-1.1.noarch
May 06 23:41:41 Updated: opsipxeconfd-4.1.1.17-1.1.noarch
May 06 23:45:12 Updated: opsi-server-4.1.1.8-1.1.noarch


Update:
Wir konnten das Problem nun beheben indem wir den Ordner /usr/lib/python2.7/site-packages/pkg_resources/ und seinen Inhalt entfernt haben, da dieser zur runtime erstellt wird. Anschließend war es möglich den opsiconfd.service wieder zu starten.

Hat jemand aus dem Forum vielleicht eine Idee warum es zu diesem Problem nach einem Update gekommen ist?

Ansonsten kann dieser Thread aber hiermit geschlossen werden.


Gruß
Dansch

[uncle_scrooge]

Nein, keine Idee. Aber ich finde das höchst interessant.

Ich fahre ein CentOS 7.8, und da gibt es /usr/lib/python2.7/site-packages/pkg_resources/ schlicht und einfach nicht. Und da wird auch zur runtime nichts erzeugt.
Was liefert RedHat bei der 7.6er an Python 2.7 aus?
Bei mir - wie gesagt, CentOS 7.8 - ist das aktuell python-2.7.5-88.el7.x86_64

(Aus reiner Neugier: Gibt es Gründe, warum ihr noch auf 7.6 seid?)