Derzeit loggt UVMMd sehr viel (Standardeinstellung Level Debug) nach /var/log/univention/virtual-machine-manager-daemon.log. Diese Datei wird durch logrotate regelmäßig umbenannt und komprimiert, ohne daß UVMMd seinerseits die neue Datei jemals öffnen, so daß alle folgenden Meldungen verloren gehen: lsof -p `pgrep -f /usr/bin/python.*univention-virtual-machine-manager-daemon` | grep /var/log univentio 4798 root 5w REG 254,0 6467971 377947 /var/log/univention/virtual-machine-manager-daemon.log.1 (deleted) In UVMMd sollte eine Möglichkeit geben, die Logfiles neu zu öffnen, z.B. durch Senden von SIGHUP. (In Python 2.6 gibt es <http://docs.python.org/library/logging.html#watched-file-handler>) Beispielcode gibt es unter <http://www.cherrypy.org/ticket/679> Alternativ ist ein Restart möglich, allerdings ist dadurch der Daemon dann eine gewisse Zeit nicht verfügbar, bis alle Daten erneut zusammengesammelt wurden.
Es sah für mich beim Testen des Sessionbroker-Server soaus, als würde er weiter in dvs-sessionbroker.log.1 loggen. Da der Code von UVMMd abgeleitet ist, sollte bei einer Behebung des Bugs im UVMMd kurz überprüft werden, ob das auch im Sessionbroker anzupassen ist.
Siehe auch Bug 20296 Comment 1
Das sollten wir umsetzen. Wenn es aufwendiger wird, dann ist auch ein Restart in Ordnung.
Der UVMMd öffnet seine Logfiles auf ein SIGHUP neu, SIGUSR1 sorgt für ein re-exec(self). Eine passende logrotate-Konfigurationsdatei wird nun mitgeliefert: Da der UVMMd derzeit noch sehr viel loggt, wird das Logfile täglich rotiert und für eine Woche aufbewahrt. Wegen Bug #20465 musste das UCR-Paket angepasst werden, um /var/log/univention/virtual-machine-manager.log von der zu weit gefassten Regel in /etc/logrotate.conf auszunehmen; dazu siehe Bug #21660. Für die QA: Im alten Logfile wird die Meldung 'Closing logfile.' und im neuen Logfile die Meldung 'Logfile reopened.' geloggt. svn22765, univention-virtual-machine-manager-daemon_0.9.143-1.145.201102251941 ChangeLog: \item Die Logdatei des UVMM wird nun täglich rotiert. Im UVMM wurde dazu die Funktion ergänzt, per \emph{SIGHUP} das Schließen und neu Öffnen der Logdatei zu veranlassen (\ucsBug{18002}).
(In reply to comment #4) > Der UVMMd öffnet seine Logfiles auf ein SIGHUP neu, SIGUSR1 sorgt für ein > re-exec(self). > Eine passende logrotate-Konfigurationsdatei wird nun mitgeliefert: Da der UVMMd > derzeit noch sehr viel loggt, wird das Logfile täglich rotiert und für eine > Woche aufbewahrt. Kann dafür auch die UCR Variable log/rotate/weeks verwendet werden?`Wir haben Kunden, die Ihre Logdateien ein Jahr aufbewahren wollen / müssen.
Die logrotate-Konfiguration wurde auf weekly und die Verwendung der UCR-Variablen log/rotate/weeks umgestellt. svn22772, 0.9.145-1.147.201102280955 ChangeLog: \item Die Logdatei des UVMM wird nun wöchentlich rotiert. Die Aufbewahrungsfrist kann über dir \ucsUCRV{log/rotate/weeks} konfiguriert werden. Im UVMM wurde dazu die Funktion ergänzt, per \emph{SIGHUP} das Schließen und neu Öffnen der Logdatei zu veranlassen (\ucsBug{20465}).
Mit einem "kill -1 3731" erhalte ich die entsprechende Meldung, die /etc/logrotate.d/univention-virtual-machine-manager-daemon muss aber noch angepasst werden: Durch die Umstellung auf runit gibt es kein /var/run/uvmmd.pid mehr. Stattdessen sollte /etc/runit/univention-virtual-machine-manager-daemon/supervise/pid verwendet werden.
Als Alternative zum vorhandenen PID-File wird nun der UVMMd per "sv HUP" zum Neu-Öffnen der Log-Files veranlasst. svn22968, univention-virtual-machine-manager-daemon_0.9.176-1.180.201103101137 Keine Änderung am ChangeLog-Eintrag.
Die UCR-Variable log/rotate/week wird ausgewertet und ist auf weekly umgestellt. Ein "logrotate -f /etc/logrotate.conf" führt zu einer rotierten Logdatei mit "2011-03-10 14:58:16,182 - uvmmd - INFO - Logfile reopened" und "2011-03-10 14:58:16,182 - uvmmd - INFO - Closing logfile." Changelog in Ordnung
UCS 2.4-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".