Bug 29247 - UVMMd hängt in poll()-Loop mit 100% CPU-Auslastung
UVMMd hängt in poll()-Loop mit 100% CPU-Auslastung
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Virtualization - UVMM
UCS 3.1
Other Linux
: P1 normal (vote)
: UCS 3.1
Assigned To: Philipp Hahn
Janek Walkenhorst
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-15 16:02 CET by Philipp Hahn
Modified: 2012-12-12 21:11 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Troubleshooting
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Hahn univentionstaff 2012-11-15 16:02:47 CET
Gewisse Ähnlichkeiten bestehen zu Bug #20296, aber an einer anderen Stelle.

UVMMd auf master und backup installiert, verwalten jeweils sich selbst und den anderen Rechner.
"strace" zeigt einen ständigen aufruf von poll() in einem Thread.

"lsof" zeigt die Socket-Verbindung zum libvirtd jeweils im "CLOSED_WAIT" state, aber es sind noch Daten abrufbar:
univentio 1734 root   11u  IPv4              13399      0t0     TCP xen2.virtualisierung.univention.test:33353->xen2.virtualisierung.univention.test:16514 (CLOSE_WAIT)
univentio 1734 root   12u  IPv4              11943      0t0     TCP xen2.virtualisierung.univention.test:55032->xen1.virtualisierung.univention.test:16514 (CLOSE_WAIT)

"gdb" zeigt, das die libvirt-Event-Handler-Funktion zwar aufgerufen wird, diese aber zurück-kehrt, ohnd die Daten zu lesen bzw, den Socket zu schließen:
#0  virNetClientIncomingEvent (sock=0x7f5614002a20, events=1, opaque=0x7f561401e550) at /var/build/temp/tmp.UZwIh0VQB4/pbuilder/libvirt-0.9.12/./src/rpc/virnetclient.c:1642
#1  0x00007f561ef4c373 in libvirt_virEventInvokeHandleCallback (self=<value optimized out>, args=<value optimized out>)
    at /var/build/temp/tmp.UZwIh0VQB4/pbuilder/libvirt-0.9.12/./python/libvirt-override.c:4412
#2  0x00000000004a7d25 in call_function (f=

(gdb) l
1641        /* This should be impossible, but it doesn't hurt to check */
1642        if (client->haveTheBuck || client->wantClose)
1643            goto done;

(gdb) print ((virNetClientPtr)opaque)->haveTheBuck
$17 = true
(gdb) print ((virNetClientPtr)opaque)->wantClose 
$18 = false
In client->msg->buffer scheint noch die Antwort auf ein "dumpxml" zu stecken: Nach einem "set variable ...->haveTheBuck=false" lief der UVMMd dann erstmal weiter und hat dann auch eine der beiden Sockets geschlossen.
Comment 1 Janek Walkenhorst univentionstaff 2012-11-15 18:00:44 CET
Dieses Problem tritt bei meiner Testumgebung häufig auf. (Jetzt schon > 5 Mal bei diversen Aktionen (Beenden, Revert))
Comment 2 Stefan Gohmann univentionstaff 2012-11-15 18:03:26 CET
Sollten sich die Probleme in den nächsten Testumgebungen bestätigen, müssen wir da zum Release noch etwas machen. Ansonsten 3.1-x.
Comment 3 Philipp Hahn univentionstaff 2012-11-19 09:13:16 CET
74bd877825190bedbd222e661449fa8b68a05b11 Revert "rpc: Discard non-blocking calls only when necessary"
wurde als libvirt/3.1-0-0-ucs/0.9.12-5/ 21_Revert-rpc-Discard-non-blocking-calls-only-when-nece.patch eingespielt.

svn11105, libvirt_0.9.12-5.117.201211190659
ChangeLog: entfällt, weil neue Version von libvirt für UCS-3.1 (Bug #27612)
Comment 4 Janek Walkenhorst univentionstaff 2012-11-19 12:59:51 CET
Lässt sich nicht mehr nachstellen.
Comment 5 Stefan Gohmann univentionstaff 2012-12-12 21:11:14 CET
UCS 3.1-0 has been released: 
 http://forum.univention.de/viewtopic.php?f=54&t=2125

If this error occurs again, please use "Clone This Bug".