Probleme mit Jenkins

[schalentier]

Hallo zusammen,

vielleicht kann mir ja hier jemand helfen. Wir setzen bei uns Jenkins als CI System in Kombination mit dem Gerrit Code Review Tool ein. Eigentlich laeuft das auch soweit alles super. Wir haben inzwischen 10 Jenkins Slaves, die die Gerrit Patchsets uebersetzen, alle Tests ausfuehren und entsprechende Packete schnueren, die dann auf Wunsch direkt ausgeliefert werden koennen.

In letzter Zeit haeufen sich allerdings sehr seltsame Probleme: Manchmal bleibt der eine oder andre Slave einfach "haengen". Das ist total zufaellig, mal der eine, mal der andre Slave (das sind btw alles virtuelle Maschinen mit einem Ubuntu drauf). Manchmal mitten in irgendwelchen Tests, manchmal erst ganz am Ende, wenn der Build eigentlich schon fertig ist.

Einziger Workaround ist derzeit, den Build abzubrechen und erneut zu starten. Bei einer Buildzeit von ca 45 Minuten ist das natuerlich sehr nervig.

Ich hab jetzt auch schon mehrere Stunden mit Google und dem Jenkins Ticketsystem verbracht, bisher ohne klares Ergebnis. Zwar gibt es etliche Probleme, die irgendwelche Deadlocks verursachen, allerdings sehen unsere Stackdumps deutlich anders aus, als die in den Bugtickets beschriebenen. Zudem sind die meisten davon bereits auf geloest gestellt und wir setzen eine recht aktuelle Jenkins Version ein.

Die Haenger wurden uebrigens richtig schlimm, als wir noch 5 weitere Slaves dazugepackt hatten. Inzwischen sind die neuen wieder deaktiviert, aber die Probleme immer noch da.

Haengt ein oder mehrere Slaves, ist auf den Rechnern (inkl. Master) weder CPU- noch IO Last. Die idlen einfach und offensichtlich warten die auf irgendwas.

Hat hier jemand schon mal aehnliche Probleme oder einen Hinweis, was wir noch ausprobieren koennten?

 

[Wildcard]

Schuss ins Blaue:
Hast du sichergestellt das die Systemuhren aller Slaves und des Masters synchron laufen?
Ich würde dafür in jedem Fall ein neues Ticket aufmachen. Vielleicht helfen die Stackdumps den Entwicklern.

 

[schalentier]

Ob du's glaubst oder nicht, dieser Gedanke kam mir auch schon - leider hab ich den als Quatsch verworfen. Nun zeigt aber sogar Jenkins die Zeitdifferenzen zu einzelnen Slaves an. Deshalb synchronisieren wir nun erstmal alle Uhrzeiten. Obs hilft wird sich dann zeigen, denn wie gesagt, der Fehler tritt nur sporadisch auf, d.h. wir koennen schlecht sagen, ob das wirklich die Ursache ist...

Danke jedenfalls und man merke sich: Manchmal sollte man doch auf seinen Bauch hoeren ^^

 

[fastjack]

Was für Tests laufen denn in den Slaves? Nur Unittests oder auch Integrationstest (die vielleicht bei paralleler Ausführung Seiteneffekte erzeugen...).

 

[schalentier]

Unit- und Integrationstests. Letztere benutzen natuerlich die Datenbank (Oracle), aber jeder Slave hat sein eignes DB-Schema. Da die Slaves in VM's laufen, sollte es eigentlich keine relevanten Seiteneffekte geben, oder was genau meinst du?

Allerdings ist es tatsaechlich so, dass der ein oder andere Build mal mitten in den Tests stehen bleibt oder es zu einem Timeout kommt (sehr selten). Das hat aber nichts mit dem oben genannten Problem zu tun, denn das tritt wie gesagt auf, wenn der Build komplett fertig ist. Es steht dann auch ein "BUILD SUCCESSFUL" im Log, aber es geht einfach nicht weiter.

Wir versuchen nun erstmal die Zeiten zu synchronisieren und sehen dann weiter. Ansonsten muessen halt die 10 Slaves (mit denen ja alles soweit klappt) reichen ;-)

 

[maki]

Wir hatten auch so usnere Probleme mit Hudson, das war 2010.

Durch das von Wildcard angesprochenen sync. Problem sind regelmässig Builds hängengeblieben, die Slaves waren aber VMs(!), es musste für Windows XP 32 Bit, Windows 7 32 Bit & 64 Bit, Ubuntu & OpenSuSE 32 & 64 bit gebaut werden, jeder Slave für eine Plattform.

Bei VMs laufen die Uhren aber sehr ungenau (Zeit "schwimmt" da eher) und die Probleme haben wir erst wegbekommen nachdem wir "echte" Maschinen als Slaves verwendet haben.

Hudson/Jenkins hat einen sehr schlechten ruf was Updates betrifft (musste ich am eigenen Leib erfahren), ist auch kein Wunder bei dem Code (Hudson bzw Jenkins Klasse ein Singleton mit ein paar Tausend zeilen und so gut wie keine tests), nach jedem Update hat etwas anderes nicht mehr funktioniert, also am besten eine Version finden die funzt und dann dabei bleiben.

 

[schalentier]

Oh man, wir hams gefunden

Der Jenkins zeigt ja immer an, welche Tests fehlgeschlagen sind und auch, wie gross die Differenz der fehlgeschlagenen Tests zum letzten Build ist. D.h. ein Build kann erst dann fertiggestellt werden, wenn der vorherige Build fertig ist (sonst kann er die Differenz nicht ausrechnen).

In unserem Fall ist nun der Effekt aufgetreten, dass ein Slave (warum auch immer) langsamer laeuft, als die anderen. Wird dieser langsame Slave nun zuerst gestartet, muessen alle nachfolgenden Builds auf eben jenen langsamen warten. *facepalm*

Beim Einsatz von Gerrit braucht man aber diese Differenz prinzipiell aber gar nicht (weil ein Patchset nicht zwingend irgendwas mit einem anderen Patchset zu tun haben muss).

Kann man das irgendwie abschalten?

Die Uhren laufen jetzt trotzdem synchron.

 

[Wildcard]

Hudson/Jenkins hat einen sehr schlechten ruf was Updates betrifft (musste ich am eigenen Leib erfahren), ist auch kein Wunder bei dem Code (Hudson bzw Jenkins Klasse ein Singleton mit ein paar Tausend zeilen und so gut wie keine tests), nach jedem Update hat etwas anderes nicht mehr funktioniert, also am besten eine Version finden die funzt und dann dabei bleiben.

Sowohl Hudson als auch Jenkins haben jetzt glücklicherweise Stable Release Trains, für alle die nicht ständig auf bleeding edge updaten wollen. Das macht die Sache deutlich stabiler.