Univention Bugzilla – Bug 29239
PackageManager sollte detailliertere Logausgaben liefern
Last modified: 2013-01-15 15:16:24 CET
Der "PackageManager" nutzt derzeit "ProgressState" (welche auch in der package_manager.py definiert ist) um die jeweiligen Aktion zu loggen. Derzeit besteht lediglich die Möglichkeit eine (oder mehrere) Logfiles zu übergeben, in denen dann die jeweilige Aktion protokolliert wird. Leider ist die Ausgabe nicht sonderlich detailiert. Es wäre vielleicht gut, wenn dies etwas überarbeitet wird, sodass man auch an detailliertere Logausgaben kommen kann; sofern dies denn möglich ist. Man könnte dabei auch auf das Python "logging"-Modul zurückgreifen, um das ganze etwas flexibler zu gestalten.
siehe auch Bug #29037
Die Log-Dateien sollten wenigstens die postinst-Ausgaben beinhalten.
*** Bug 29762 has been marked as a duplicate of this bug. ***
Mit folgendem Patch wird in /tmp/ eine Datei angelegt, die die Logausgaben enthält. Für jeden "dpkg"-Aufruf wird ein neues Tempfile erzeugt. Wird die Variable "tmp" durch ein normales File-Objekt ausgetauscht, sollten die Logausgaben auch leicht z.B. in die updater.log umgeleitet werden können. --- a/ucs/base/univention-lib/python/package_manager.py +++ b/ucs/base/univention-lib/python/package_manager.py @@ -185,7 +185,7 @@ class DpkgProgress(apt.progress.base.InstallProgress): def fork(self): # we better have a real file # when using low-level routines - tmp = tempfile.TemporaryFile() + tmp = tempfile.NamedTemporaryFile(delete=False) msg_writer = MessageWriter(self.progress_state, tmp) p = os.fork() if p == 0:
(In reply to comment #4) > Mit folgendem Patch wird in /tmp/ eine Datei angelegt, die die Logausgaben > enthält. Für jeden "dpkg"-Aufruf wird ein neues Tempfile erzeugt. Wird die > Variable "tmp" durch ein normales File-Objekt ausgetauscht, sollten die > Logausgaben auch leicht z.B. in die updater.log umgeleitet werden können. > > --- a/ucs/base/univention-lib/python/package_manager.py > +++ b/ucs/base/univention-lib/python/package_manager.py > @@ -185,7 +185,7 @@ class DpkgProgress(apt.progress.base.InstallProgress): > def fork(self): > # we better have a real file > # when using low-level routines > - tmp = tempfile.TemporaryFile() > + tmp = tempfile.NamedTemporaryFile(delete=False) > msg_writer = MessageWriter(self.progress_state, tmp) > p = os.fork() > if p == 0: Super, das funktioniert ja hervorragend. Ich habe jetzt ein systemweites Log eingeführt: /var/log/univention/package_manager.log - da geht jetzt einfach alles rein, inklusive dpkg-Output (allerdings mit vielen hässlichen versuchten "\r", die natürlich nicht funktionieren). Damit ist /var/log/univention/appcenter.log im Prinzip obsolet. Allerdings gehen in die andere Datei auch Informationen beim System Setup und bei der normalen Paketinstallation (aber die beiden Anwendungsfälle sollten sich in Grenzen halten). Für 3.1-1 univention-management-console-module-appcenter 2.0.92-1.38.201212142148 univention-lib 2.0.20-1.112.201212142146
Created attachment 4937 [details] Write detailed dpkg-log output Patch für das Errata-Update. Neue Log-Datei (gilt für das App Center und System Setup): /var/log/univention/package_manager.log
Wie besprochen noch einmal auf. * Bitte den Link für den Workaround mit os.dup2() im Code angeben: https://bugs.launchpad.net/jockey/+bug/280291 * /var/log/package_manager.log ist verwirrend, da dort Inhalte verschiedener Module gesammelt würden. Die DPKG-Ausgaben können besser (bspw. mit Hilfe einer Named Pipe → os.mkfifo()) gesammelt und mit einem kleinen Thread über univention.debug() bei Loglevel INFO entsprechend formatiert ausgegeben werden.
(In reply to comment #7) > Wie besprochen noch einmal auf. > > * Bitte den Link für den Workaround mit os.dup2() im Code angeben: > https://bugs.launchpad.net/jockey/+bug/280291 > Ist jetzt drin. > * /var/log/package_manager.log ist verwirrend, da dort Inhalte verschiedener > Module gesammelt würden. Die DPKG-Ausgaben können besser (bspw. mit Hilfe einer > Named Pipe → os.mkfifo()) gesammelt und mit einem kleinen Thread über > univention.debug() bei Loglevel INFO entsprechend formatiert ausgegeben werden. Habe mich leicht anders entschieden. Die Meldungen kommen nicht ins Log, sondern werden an den info_handler übergeben. Vorteile: 1. Das Modul kann selbst entscheiden, wie mit der Nachricht verfahren wird (App Center: MODULE.info, System setup: __MSG__). 2. Das Frontend bekommt die Meldungen auch mit. Durch (2.) kriegen wir hier Bug#29887 geschenkt. Fixed in univention-lib 2.0.17-1.116.201301031745
Comment on attachment 4937 [details] Write detailed dpkg-log output Es gibt nun keine dezidierten Logdateien mehr, in die der PackageManager schreibt. Es liegt im Ermessen des Modul-Entwicklers. Weder /var/log/univention/package_manager.log noch /var/log/univention/appcenter.log existieren noch.
(In reply to comment #8) > (In reply to comment #7) > > Wie besprochen noch einmal auf. > > > > * Bitte den Link für den Workaround mit os.dup2() im Code angeben: > > https://bugs.launchpad.net/jockey/+bug/280291 > > Ist jetzt drin. OK > > * /var/log/package_manager.log ist verwirrend, da dort Inhalte verschiedener > > Module gesammelt würden. Die DPKG-Ausgaben können besser (bspw. mit Hilfe einer > > Named Pipe → os.mkfifo()) gesammelt und mit einem kleinen Thread über > > univention.debug() bei Loglevel INFO entsprechend formatiert ausgegeben werden. > > Habe mich leicht anders entschieden. Die Meldungen kommen nicht ins Log, > sondern werden an den info_handler übergeben. > Vorteile: > 1. Das Modul kann selbst entscheiden, wie mit der Nachricht verfahren wird (App > Center: MODULE.info, System setup: __MSG__). > 2. Das Frontend bekommt die Meldungen auch mit. Ja, super :) ! > output = os.read(self.pipe_read, 2048) > for line in output.split('\n'): > for subline in line.split('\r'): Es ist vielleicht sicherer mit os.fdopen() zu arbeiten. Die Methode liefert ein File-Objekt zurück, das Handling wäre dann klarer, da mit file.readline() gearbeitet werden kann.
(In reply to comment #10) > ... > Es ist vielleicht sicherer mit os.fdopen() zu arbeiten. Die Methode liefert ein > File-Objekt zurück, das Handling wäre dann klarer, da mit file.readline() > gearbeitet werden kann. Vielleicht doch keine bessere Idee, nicht fertige Zeilen würden dann nicht zurückgegeben (IMHO), siehe auch: > http://stackoverflow.com/questions/2093788/python-readline-on-a-pipe-that-has-been-opened-as-non-blocking Anderer Vorschlag: > for line in output.split('\n'): > for subline in line.split('\r'): Könnte durch: > for line in output.splitlines(): ersetzt werden. Aber das ist nicht wirklich kritisch, daher nochmal auf RESOLVED.
Änderungen: OK (appcenter + system-setup) YAML-Datei: OK Übernahme nach 3.1-1: OK Changelog 3.1-1: OK
YAML-Datei: 2013-01-04-univention-lib.yaml
http://errata.univention.de/3.1-errata12.html