opsiconfd - Problem nach Opsi 4.1 Minor Update
opsiconfd - Problem nach Opsi 4.1 Minor Update
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
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
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
Hi
Schau doch mal ins Log des opsiconfd
Gruß
Mathias
Schau doch mal ins Log des opsiconfd
Code: Alles auswählen
/var/log/opsi/opsiconfd/opsiconfd.log
Mathias
Kein Support per DM!
_________________________
opsi support - http://www.uib.de/
For productive opsi installations we recommend support contracts.
_________________________
opsi support - http://www.uib.de/
For productive opsi installations we recommend support contracts.
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
Hi Mathias,
die Logdatei ist leider leer.
Gruß
Dansch
die Logdatei ist leider leer.
Gruß
Dansch
- SisterOfMercy
- Beiträge: 1524
- Registriert: 22 Jun 2012, 19:18
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
Have you tried the default stuff to fix things?
IE:
IE:
Code: Alles auswählen
opsi-setup --set-rights
opsi-setup --auto-configure-samba
opsi-setup --init-current-config
Bitte schreiben Sie Deutsch, when I'm responding in the German-speaking part of the forum!
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
Starte einfach mal den opsiconfd in der Konsole/Terminal und sieh Dir die Fehlermeldung an.
Gruß
Mathias
Gruß
Mathias
Kein Support per DM!
_________________________
opsi support - http://www.uib.de/
For productive opsi installations we recommend support contracts.
_________________________
opsi support - http://www.uib.de/
For productive opsi installations we recommend support contracts.
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
@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
@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
-
- Beiträge: 650
- Registriert: 21 Feb 2012, 12:03
- Wohnort: Mainz
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
Welches System? Debian, Ubuntu, CentOS,....
>>Minor Update von Opsi 4.1
Von welcher Version auf welche Version?
>>Minor Update von Opsi 4.1
Von welcher Version auf welche Version?
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
@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
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
-
- Beiträge: 650
- Registriert: 21 Feb 2012, 12:03
- Wohnort: Mainz
Re: opsiconfd - Problem nach Opsi 4.1 Minor Update
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?)
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?)