OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Antworten
feltel
Beiträge: 213
Registriert: 09 Dez 2014, 07:22

OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Beitrag von feltel »

Bei den letzten beiden OPSI 4.2-Debian-Paketupgrades des opsiconfd fiel mir auf, das der opsiconfd-Daemon nach dem Upgrade nicht neu gestartet wird. Entweder hängt dann noch ein Zombie-Prozess rum oder aber gar keiner mehr. Man muss dann immer händisch ein "systemctl start opsiconfd.service" abfeuern. Kein großes Ding, solange man Sachen wie unattended-upgrades [1] nicht nutzt. Das Paket kann den Neustart des Daemon ja aber im Rahmen des Upgrades selbst erledigen.

[1] https://wiki.debian.org/UnattendedUpgrades
kinzi
Beiträge: 166
Registriert: 27 Okt 2010, 11:38

Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Beitrag von kinzi »

Hatte ich auch, das hat geholfen:

viewtopic.php?f=7&t=11506

Gruß
kinzi

P. S.: Zuvor war noch ein

Code: Alles auswählen

apt install opsiconfd --reinstall
bei mir notwendig.
Benutzeravatar
ueluekmen
uib-Team
Beiträge: 1939
Registriert: 28 Mai 2008, 10:53

Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Beitrag von ueluekmen »

Falls sich jemand hier vorbeikommt, der Link weist auf eine Lösung für opsi 4.1 hin. Die genannte Option gibt es in opsi 4.2 nicht mehr.

Meine Kollegen schauen sich das Problem mit den Debian Paketen noch mal genauer an und melden sich hierüber oder direkt per Release. ;)
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
Benutzeravatar
fkalweit
uib-Team
Beiträge: 173
Registriert: 23 Okt 2020, 16:14

Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Beitrag von fkalweit »

Hallo,

ich konnte den Fehler mit den neusten Versionen (opsiconfd 4.2.0.175 und 4.2.0.177) leider nicht nachstellen (Debian 10).

Lässt sich der opsiconfd mit

Code: Alles auswählen

opsiconfd stop
und mit

Code: Alles auswählen

opsicofd start -l=5
ganz normal starten und stoppen?
Was passiert, wenn das postinst

Code: Alles auswählen

/var/lib/dpkg/info/opsiconfd.postinst configure
manuell ausgeführt wird?
Welche Versionen haben die anderen Opsi Pakete?

Code: Alles auswählen

dpkg -l | grep opsi
Viele Grüße
fkalweit
feltel
Beiträge: 213
Registriert: 09 Dez 2014, 07:22

Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades

Beitrag von feltel »

Hallo,
ja, der opsiconfd lässt sich mit "opsiconfd stop" wie auch mit "systemctl ..." stoppen, auch mit dem "-l=5"-Argument. Starten ebenfalls. Beim manuellen Ausführen des postinst-Scriptes kommt:

Code: Alles auswählen

root@centaur:~# /var/lib/dpkg/info/opsiconfd.postinst configure
[5] [2021-06-16 12:17:12.533] [               ] Running opsiconfd setup   (setup.py:190)
[5] [2021-06-16 12:17:12.896] [               ] Creating base path: '/var/lib/opsi/config'   (File.py:216)
[5] [2021-06-16 12:17:12.959] [               ] Creating opsi base   (SQL.py:586)
[5] [2021-06-16 12:17:13.260] [               ] Setting up default values.   (ConfigurationData.py:64)
[5] [2021-06-16 12:17:13.422] [               ] Finished setting up default values.   (ConfigurationData.py:72)
[5] [2021-06-16 12:17:13.640] [               ] Connection to database 'opsi' on 'localhost' as user 'db_opsi'   (MySQL.py:65)
[5] [2021-06-16 12:17:14.158] [               ] Creating opsi base   (SQL.py:586)
[5] [2021-06-16 12:17:15.787] [               ] Setting rights on '/etc/shadow'   (Rights.py:239)
[5] [2021-06-16 12:17:15.788] [               ] Setting rights on '/var/log/opsi/opsiconfd/opsiconfd.log'   (Rights.py:239)
[5] [2021-06-16 12:17:15.789] [               ] Setting rights recursively on '/etc/opsi'   (Rights.py:239)
[5] [2021-06-16 12:17:15.790] [               ] Setting rights recursively on '/etc/opsi/ssl'   (Rights.py:239)
[5] [2021-06-16 12:17:15.790] [               ] Setting rights on '/etc/opsi/ssl/opsi-ca-cert.pem'   (Rights.py:239)
[5] [2021-06-16 12:17:15.791] [               ] Setting rights on '/etc/opsi/ssl/opsi-ca-cert.pem'   (Rights.py:239)
[5] [2021-06-16 12:17:15.791] [               ] Setting rights on '/etc/opsi/ssl/opsi-ca-key.pem'   (Rights.py:239)
[5] [2021-06-16 12:17:15.792] [               ] Setting rights on '/etc/opsi/ssl/opsiconfd-cert.pem'   (Rights.py:239)
[5] [2021-06-16 12:17:15.793] [               ] Setting rights on '/etc/opsi/ssl/opsiconfd-key.pem'   (Rights.py:239)
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
root@centaur:~#
Die OPSI-Pakete und auch alle anderen installierten Pakete sind tagaktuell:

Code: Alles auswählen

root@centaur:~# dpkg -l|grep opsi
rc  opsi-atftpd                    0.7.dfsg-7                    amd64        advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                  4.0.7.6.34-2                  all          OPSI config editor
ii  opsi-linux-bootimage           20210519-1                    all          opsi bootimage for netboot tasks.
ii  opsi-server                    4.2.0.54-1                    all          opsi server
ii  opsi-tftpd-hpa                 5.2.8-72                      amd64        HPA's tftp server
ii  opsi-utils                     4.2.0.103-1                   amd64        Utilities for working with opsi
ii  opsiconfd                      4.2.0.175-1                   amd64        opsi configuration service
ii  opsipxeconfd                   4.2.0.17-1                    amd64        opsi pxe configuration service
rc  python-opsi                    4.1.1.101-1                   all          opsi python library
Wir haben hier mehrere OPSIs laufen, die sind alle gleich aufgebaut, werden aber unabhängig voneinander gepflegt/aktualisiert etc. Die VMs wurden auch alle seinerzeit separat installiert und stammen nicht von einer gleichen Ursprungs-VM ab. Aber bei allen OPSIs fiel das genannte Verhalten auf bei den letzten beiden opsiconfd-Paketupdates (.174 und .175) auf.

Ich würde ggf. jetzt mal das nächste Paketupdate abwarten, ob da der Fehler gleichartig wieder auftritt.
Antworten