Libelektra: Server-Sachen erstellen

@markus2330

Habe gerade ein paar Build-System-bezogene Fixes gepusht. Aber Sie müssen auch einige Pakete auf Ihrem stabilen debian-stable-Rechner reparieren:

• Bitte installieren Sie qtdeclarative5-dev von wheezy-backports (Sie können /opt/Qt5.3.0 danach entfernen)
• Bitte installieren Sie Java8 als Paket:
  
  
  
  • Verwenden Sie diese Methode: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • Lassen Sie cmake tatsächlich jdk8 finden: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • kill + den lokalen Jenkins-Java-Prozess neu starten. Andernfalls schlagen alle Builds fehl
  
  
  • Optional: jdk7 entfernen
  
  

Sieht gut aus, danke für die Behebung dieser Probleme.

Ich habe diese Schritte auch auf dem debian-stable-Agenten durchgeführt.

Auf anderen Maschinen war die Installation von qtdeclarative5-dev nicht möglich, da es mit qdbus, das von kde4 benötigt wird, in Konflikt steht. Also habe ich das vorherige Skript configure-debian-wheezy als configure-debian-wheezy-local wiederhergestellt.

Ich habe die von Ihnen erwähnten Installationsschritte auch als Hinweise in der README.md hinzugefügt, da sie für andere von Interesse sein könnten.

Vielen Dank für das Upgrade der Agenten!

Sachen, die auf Stall fehlen

1.) Latex (+ ich denke, Texlive-Latex-empfohlen wird auch benötigt)
siehe http://build.libelektra.org :8080/job/elektra-doc/495/console

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) Kannst du clang installieren (bei elektra-clang funktioniert clang of wheezy nicht)?
3.) Können Sie mingw+wine für elektra-gcc-configure-mingw installieren?

apt install --no-install-recommends doxygen-latex + klingeln + mingw fertig

Warum brauchen Sie Wein?

Übrigens, Sie sollten i586-mingw32msvc-X in i686-w64-mingw32-X in Toolchain-mingw32.cmake i686-w64-mingw32-X ändern. Im Moment funktioniert dies nicht auf instabil.

Danke für Doku!

wine wird benötigt, um die kreuzkompilierten Windows-Binärdateien auszuführen (zB exporterrors.exe)

Ich denke, Sie haben das mingw installiert, das für w64 erstellt wird. Im mingw32-Paket gibt es immer noch ein /usr/bin/i586-mingw32msvc-c++ .

Eine neue Toolchain-Datei für w64 wird dennoch geschätzt.

Ich habe gcc-mingw-w64-i686 installiert, das ist der x64-Build von mingw mit i686 als Ziel.
Das Paket mingw32-binutils ist veraltet und auf Unstable nicht mehr verfügbar.

Wine auf beiden Containern installiert.

Eigentlich ist der mingw-Build an Stable gebunden, also sollte das kein Problem sein.

MinGW-w64 ist ein Fork von mingw und ist ein ganz anderes Ziel. Das hat bis jetzt niemand getestet.

Danke für die Installation von Wein

Mingw-w64 sieht überlegen aus. Vielleicht ist es an der Zeit, weiterzumachen :-)

Beiträge willkommen ;) Ich habe keine Maschine, um es zu testen.

Ich fürchte, Sie haben den falschen Wein erhalten, es sollte apt-get install wine32 sein

siehe auch http://build.libelektra.org :8080/job/elektra-gcc-configure-mingw/218/console

Nö.

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

ok, dpkg --add-architecture i386 wird das lösen. Aber können Sie den mingw/wine-Job nicht einfach an Ihre Baumaschine anheften? Das mingw-Setup ist ziemlich speziell.

Bearbeiten: Ich werde sehen, ob ich Elektra mit mingw-w64 bauen kann, damit ich nicht Tonnen von i686-Bibliotheken installieren muss.

Das Problem ist, dass ich keinen Ersatz-Jessie-Rechner habe und Wheezys mingw C++11 nicht kennt.

Ich habe es geschafft, mingw-w64 zum Laufen zu bringen. std::mutex ist jedoch nicht verfügbar, da es keine glibc unter Windows gibt und std::mutex von pthreads abhängt. Irgendwelche Ideen?

Wow, danke!

Führt es zu einem Kompilierungsfehler? Der std::mutex wird nicht für interne
Funktionalität, aber nur in einer Header-Datei, die von einem Benutzer eingefügt werden soll. Es ist benutzt
allerdings in Testfällen.

Eine Lösung für Kompilierungsprobleme ist die Bereitstellung eines std::mutex im mingw
Fall, der bei jedem Versuch zum Sperren/Entsperren Systemfehler auslöst. Eigentlich würde ich
erwarten, dass die mingw-Leute zumindest so etwas liefern (z. B. wenn
ein Makro ist gesetzt, ähnlich wie -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads könnte ein anderer Weg sein. Das ist aber
höchstwahrscheinlich nur nützlich, wenn alle Testfälle außer denen mit std::mutex
schon laufen.

Im Grunde ist dies nur eine Instanz von C++11, die nicht richtig verfügbar ist.

mingw-Status im Moment:

• dlfcn-win32 als externes Projekt zum libloader hinzugefügt. Auf diese Weise checkt cmake die Bibliothek aus und kompiliert sie als zusätzlichen Build-Schritt. Ich verlinke das Archiv, um zusätzliche DLL-Deps zu vermeiden.
• winsock2.h/ws2_32.dll-Abhängigkeit zu cpp11_benchmark_thread hinzugefügt. erforderlich von gethostname()-Aufruf

Im Moment baue ich mit -static-libgcc + -static-libstdc++ . Andernfalls kann Wine die DLLs nicht finden. Zusätzlicher Mutex kompiliert auch nicht. Ich habe es mit mingw-std-threads versucht. habe gerade mehr Kompilierungsfehler bekommen :-)

Wenn ich von x86_64-w64-mingw32-X zu x86_64-w64-mingw32-X-posix wechsle, kompiliert std::mutex gut, weil pthread-Zeug definiert ist. Allerdings bekomme ich eine zusätzliche Abhängigkeit von libwinpthread-1.dll, die Wine nicht finden kann.

Ich denke, unsere beste Wahl ist jedoch, x86_64-w64-mingw32-X-posix .

Auch hier bin ich überrascht, dass Sie dieses Problem überhaupt haben. Bisher haben wir uns gefreut, als wir eine libelektra.dll bekommen haben.

Zu dieser x86_64-w64-mingw32-X-posix Entscheidung kann ich nichts sagen, weil ich sie nicht verwende und die Auswirkungen nicht kenne. Ich wundere mich, dass eine solche Posix-Lib überhaupt existiert, ich dachte, dass der Posix-Layer-Ansatz cygwin und nicht mingw ist.

Wirkt sich diese Entscheidung überhaupt auf libelektra.dll aus? Wenn es nur für die Testfälle ist, wird es niemanden interessieren (solange der Build-Server in der Lage ist, ihn auszuführen). Wenn die Testfälle ausgeführt werden, ist dies ein großer Vorteil. (Siehe #270, wo die Komponententests einige seltsame Fehler unter Mac OS X enthüllten)

Es scheint, dass libwinpthread-1.dll heruntergeladen werden kann, ich weiß jedoch nicht, ob sie mit Wein funktionieren? Kann man es auch wie bei dlfcn-win32 als externes Projekt hinzufügen (damit alle DLLs gleich behandelt werden)? Andernfalls spielt es möglicherweise keine Rolle, ob Sie 1 oder 3 DLLs für die Tests herunterladen müssen (wiederum bin ich kein Benutzer und verstehe das Bereitstellungskonzept von Windows-DLLs nicht, falls vorhanden).

@beku Was denkst du? Haben Sie Zeit, unser neuestes 0.8.13 mingw-w64-Build unter Windows zusammen mit oyranos zu testen?

Sind Tests normalerweise für den mingw-Build-Job aktiviert? Gestern waren alle behindert.

Ja, sie waren behindert. Aber auch einige Beispiele/Benchmarks wie cpp11_benchmark_thread wurden deaktiviert. Also dachte ich, Sie hätten es geändert und mehr kompiliert als zuvor.

Ich habe das gesamte Repo mit aktiviertem C++11 kompiliert. Nichts mehr.

Aber ausführbare Dateien wie bin/basename.exe, die mit -posix erstellt wurden, laufen gut, solange Sie die erforderlichen DLLs in das bin-Verzeichnis kopieren (danke Windows, dass Sie kein RPATH haben). Ich habe keine Möglichkeit gefunden, a) cmake das DLL-Verzeichnis finden zu lassen + b) Wine auf das DLL-Verzeichnis zu verweisen.
Ich dachte, statisches Verknüpfen würde funktionieren, aber dann schlägt der Build mit doppelten Symbolen beim Verknüpfen der elektra dll fehl. Weil die DLL bereits die Symbole enthält.

@markus2330 Ich habe es geschafft, elektra mit mingw + zum Laufen mit wine zu kompilieren, ohne DLLs zu kopieren. Der Trick besteht darin, immer statisches Verknüpfen sowohl für ausführbare als auch für gemeinsame Objekte zu aktivieren ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ").

Um doppelte Symbole zu umgehen, habe ich Versionsskripte für libelektra und libelektratools hinzugefügt. Auf diese Weise werden nur unsere Symbole exportiert.

Das funktioniert wirklich gut. z.B

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

Sogar bin/cpp11_benchmark_thread.exe funktioniert.

Andere Dinge stürzen einfach ab:

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

Im Moment habe ich einfach das Versionsskript-Zeug hinzugefügt, ohne über andere Compiler nachzudenken. Soll ich meine Arbeit fortsetzen oder kein Interesse?

stürzt in src/plugins/wresolver/wresolver.c ab, weil pk->filename NULL ist

pk ist vom Typ resolverHandles.user

Ich habe versucht, einen Blick auf das Plugin zu werfen, aber ich verstehe die for-Schleife in elektraWresolverOpen . Die Schleife ruft elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System} was alle malloc resolverHandle->filename und somit Speicherlecks sind.

Danke für den Hinweis! Der Code ist offensichtlich seit der Einführung in c87ae8e87a716b02b2c7ed790ad56a89d95547a9 gebrochen
Nur beim Schleifen und immer wurde das Systemhandle initialisiert. Dies führte zu Abstürzen, wenn ein anderer Namespace verwendet wurde.

Ich habe es repariert
edb4d50856bb5331749220de5a83fa2062624a9d

Apropos Weiterarbeit: Einerseits wäre es schön, wenn das kompilierte Zeug auch läuft. Auf der anderen Seite sollte die Veröffentlichung dieses Wochenende erfolgen, daher wäre bald ein Pull-Request wichtig (es sollte zumindest eine Chance auf einen kurzen Feedback-Kreis geben, z. B. was die Versionsskripte eigentlich tun)

Aber imho reicht es, wenn nur eine Variante (die statische Kompilierung) funktioniert. Schön zu sehen, wie das kdb-Tool läuft!

Wo finde ich edb4d50856bb5331749220de5a83fa2062624a9d?

edb4d50856bb5331749220de5a83fa2062624a9d wurde etwas später gepusht.

Welche gcc-Versionen sind auf debian-unstable-mm installiert?

http://build.libelektra.org :8080/job/elektra-multiconfig-gcc-unstable/build_type=Release,gcc_version=5.2,plugins=ALL/56/console

sagt, es gibt kein gcc-5.2

Können Sie bitte so viele Compiler wie möglich installieren?

In einigen Ausgaben oder PR habe ich gesagt, dass ich alle Compiler außer den neuesten entfernt habe.
Bearbeiten: gcc 4.9 auf Stable, 4.9 + 5.x (Standard) auf Unstable

Bitte machen Sie diese Art von Tests (ich finde sie sowieso sehr unnötig) an Ihren eigenen Containern. Meiner wird sowieso nicht ewig bleiben.

Das habe ich nicht gelesen. Sie haben vielleicht jeweils 50 MB. Könnten Sie sie bitte erneut installieren und die erste Frage beantworten?

Vielleicht habe ich es dir bei unserem Treffen gesagt. Aber ich habe es dir definitiv gesagt.

debian-unstable:~ # gcc -v 2>&1 | tail -n 1
gcc version 5.2.1 20150903 (Debian 5.2.1-16)

Die versionspezifische Binärdatei heißt gcc-5. Kein separates Paket für Nebenversionen mehr. Ihr multiconfig-gcc mit diesem Detaillierungsgrad ist also irgendwie veraltet. Ich empfehle gcc 4.7 zu entfernen und gcc-5.2 durch gcc-5 zu ersetzen und fertig.

Der einzige verfügbare zusätzliche Compiler, den ich nicht installiert habe, ist gcc-4.8. Und gcc-4.8 wurde bereits zum Entfernen markiert.

Danke für die Information! Scheint, als ob die glorreichen Tage vieler verfügbarer Compiler vorbei sind.

Ich habe multiconfig-unstable behoben.

Ich schließe vorerst, danke für die hervorragende Agentenkonfiguration.

Hallo, Jessie (Stall) braucht noch ein paar Pakete. Könntest du bitte installieren:

• [ ] Fakeroot
• [ ] gpg (+ Schlüssel für Autobuilder erstellen [email protected])
• [ ] Reprepro (vielleicht schon installiert, Skript ging nicht so weit)

fakeroot installiert, gpg + repropro ist bereits installiert.
Können Sie mir Ihren bereits vorhandenen gpg-Schlüssel zusenden? Also haben beide Build-Maschinen das gleiche

Es ist in Ordnung, verschiedene gpg-Schlüssel zu haben. Ich bin mir nicht sicher, ob das aktuelle Setup sie überhaupt verwendet, also warten Sie zuerst, wenn http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/ fehlschlägt.

• debhelper + libsystemd-journal-dev installiert
• python-dev ist eine falsche Abhängigkeit. es sollte python2.7-dev oder python3-dev oder beides sein
• Warum brauchen wir Python-Unterstützung?

Danke für die Installation!

python-dev ist für Jessie und auch python-support verfügbar. Bitte installieren Sie sie.

Ich habe es lokal getestet, wenn diese Pakete installiert sind, baut es für Jessie.

Sicher, es ist verfügbar, aber es ist eine falsche Abhängigkeit. python-dev hängt von python2.7-dev ab, was _nicht_ ausreicht. Stattdessen ist python2.7-dev + python3-dev erforderlich.

Python-Unterstützung ist imho überhaupt nicht erforderlich.

Ich weiß nicht, warum die Abhängigkeiten auf diese Weise gewählt wurden, das meiste Packen wurde von

Ja, die Pakete sollten auch aktualisiert werden, um Python3-Bindungen zu erstellen. Derzeit ist es einfach nicht fertig. Trotzdem können Sie python3-dev installieren, damit der Build nicht kaputt geht (wenn Python3-Bindungen+Plugins zum Debian-Paket hinzugefügt werden).

Das bedeutet nicht, dass sie richtig sind :-) - Ich bin mir ziemlich sicher, was die Python-Dev-Deps angeht.
Können Sie sie bitte ersetzen und die Python-Support-Dep entfernen?

python3-dev und python2.7-dev ist bereits installiert. Sonst würde keine Bindung entstehen.

Übrigens. das offizielle debian- paket von @pinotree ist sowieso überlegen.

Wenn ich Zeit finde, werde ich unseren "debian"-Zweig auf das aktualisieren , was

Ich habe nie gesagt, dass ich die Python2-Pakete entfernen werde. Ich sage nur, dass Python-dev eine ungenaue Abhängigkeit ist. Wir benötigen explizite Versionen. PythonX-dev ist also das richtige Dep.

Hoffentlich hat Pinotree die Abhängigkeit richtig ausgearbeitet.

Übrigens, Gepard ist tot. Verwenden Sie es nicht.

Okay, ersetzt. Bitte setzen Sie b7c266b36b0ab0fad9120e67a457b580c7c44690 zurück und installieren Sie die Python-Unterstützung, wenn sie doch benötigt wird.

Ich bin mir sicher, dass Pinotree es richtig gemacht hat ;)

Und es sagt: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org :8080/job/elektra-git-buildpackage-jessie/3/console

Eingerichtet

python-dev ist eine falsche Abhängigkeit. es sollte python2.7-dev oder python3-dev oder beides sein

• python-dev installiert das Entwicklungspaket für die Standardversion von Python 2; seit Wheezy ist das Python 2.7
• python3-dev installiert das Entwicklungspaket für die Standardversion von Python 3; Python 3.2 in Wheezy, 3.4 in Jessie und bisher noch 3.4 in Stretch (ich glaube bald 3.5)

Wenn Sie also gegen die Standardversion von Python 2/3 bauen möchten, verwenden Sie jeweils python-dev / python3-dev , nicht die pythonX.Y-dev Versionen (die Sie verwenden müssen, wenn Sie explizit eine genaue Python-Version installieren möchten, auch wenn nicht die einzige auf dem System installiert ist und nicht die Standardversion). Beides zu verwenden ist das, was ich empfehle.

von python-dev Beschreibung:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

Laut diesem Text kann python-dev sicher irgendwann auf python3 angewiesen sein

Außerdem: Es wird nie wieder eine Python2-Version geben. python2.7-dev wird also das letzte python2-Entwicklungspaket aller Zeiten sein.

Abhängig von python3-dev ist das, was ich gesagt habe.

Jetzt fehlt nur noch der Schlüssel:

gpg: new configuration file `/home/jenkins/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/jenkins/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/jenkins/.gnupg/secring.gpg' created
gpg: keyring `/home/jenkins/.gnupg/pubring.gpg' created
gpg: skipped "Autobuilder <[email protected]>": secret key not available
gpg: /tmp/debsign.DlSdnFtB/elektra_0.8.13-1.41.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/08C91995 2015-09-30
      Key fingerprint = BA4C 688E 9071 FD3F 57ED  E9D6 D0A9 EDB9 08C9 1995
uid                  Autobuilder <[email protected]>
sub   2048R/E69F110A 2015-09-30

getan

Dankeschön!

Bitte exportieren Sie /home/jenkins/repository über http.

cannot access /home/jenkins/repository: No such file or directory ?

→ http://194.117.254.29/elektra-stable/

@manuelm Könnten Sie bitte ronn auf den Agenten installieren? (wird zum Generieren von Manpages benötigt)

apt-get install ruby-ronn

getan

Danke, Jessie-Pakete werden wieder erstellt und man-Seiten sind jetzt enthalten!

Bitte installieren Sie musl, dh

apt-get install musl musl-dev musl-tools

Dankeschön!

musl installiert und Agends aktualisiert

Zwei wichtige Dinge über den Build-Server:

1. Erstellen Sie keine neuen leeren Jobs, sondern duplizieren Sie sie, sie haben die richtigen Einstellungen (außer was in Nummer 2 erwähnt wurde).
2. Wir sollten Referenzklone verwenden (in /home/jenkins/libelektra) oder flache Klone für jeden Build-Job bevorzugen (derzeit nur für einige, zB elektra-clang). Derzeit beträgt der Traffic bei Commits aufgrund der vielen unnötigen Reklone >300 MB.

@mpranj Es wäre toll, wenn Sie 2 reparieren könnten.

@markus2330 nur um sicherzugehen: Ich sollte einfach das gleiche elektra-clang ?

Flache Klone, die auf alle Build-Jobs angewendet werden, außer :

• [ ] elektra-git-buildpackage-jessie
• [ ] elektra-git-buildpackage-wheezy
• [ ] elektra-multiconfig-gcc-stable
• [ ] elektra-multiconfig-gcc-unstable
• [ ] elektra-source-package-test

Diese Jobs checken in ein Unterverzeichnis aus. Ich war mir nicht sicher, was du da willst, also lasse ich sie vorerst so, wie sie sind.

Dankeschön! Ja, sie brauchen eine vollständige Historie und Verzweigungen, flache Klone machen keinen Sinn, aber das Referenzklon-Repository wäre nützlich.

Jenkins wurde auf 1.651.2 aktualisiert. Auch alle Plugins wurden aktualisiert.

Ich werde das Problem für die Referenzklon-Repos offen halten. Wir sollten auch "Cronjobs" haben, die die Repos von Zeit zu Zeit aktualisieren, idealerweise mit Jenkins selbst.

Jenkins hat den Aufbau einiger Jobs eingestellt (anscheinend seit dem Update). Es scheitert mit
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Danke für die Information. Ich versuche, den github Request Builder von 1.31 auf 1.14 herunterzustufen.

Jetzt scheint es beim Setzen des Build-Status für den Github-Commit hängen zu bleiben. Es warnt, dass dies in der Konfiguration veraltet ist.

Ich habe auch versucht, jedes Plugin mit *git* im Namen downzugraden, aber dann gab es immer noch Fehler (seltsamer Fehler im Zusammenhang mit Mailer-Plugin, Downgrade des Mailer-Plugins hat nicht geholfen). Also habe ich alles wieder auf aktuelle Versionen aktualisiert. Das Problem scheint ein bekanntes Problem im Upstream zu sein:

https://github.com/janinko/ghprb/issues/347

Ich hoffe, sie werden es bald beheben.

Eine andere Frage: Weiß jemand, wie man mehrere Jobs für jede PR durchführt? (Ich möchte sowohl elektra-mergerequests-stable als auch elektra-mergerequests-unstable ausführen)

Der Job elektra-test-bindings funktioniert gut mit parametrisierten Builds (wie auch im Upstream-Ticket beschrieben). Könnten wir es nicht einfach auf parametrisierte Builds umstellen? Der Fehler wurde seit einiger Zeit im Upstream gemeldet, ich sehe ihn nicht bald behoben.

Gute Idee, wir könnten alle PR-Jobs auf parametrisierte Builds umstellen, das hat eigentlich nur Vorteile. Es ermöglicht uns, die Jobs auch manuell auszuführen, indem wir einen Zweig angeben. Und es kann auch für regelmäßige Bauarbeiten verwendet werden.

Im Idealfall könnte jeder Job auch von github PRs ausgeführt werden. (Außer denen speziell für Nicht-PR-Aufgaben, die Doku oder Abdeckung des Master-Zweigs aktualisieren)

Ein Nachteil der Konfiguration von elektra-test-bindings ist, dass sie nur Polling durchführt und ziemlich lange dauert, bis sie mit dem Aufbau beginnt (bis zu 5 min). Ich möchte "Use github hooks for build triggering" jedoch nicht aktivieren, um den Build-Job nicht zu unterbrechen.

Übrigens. Sind Sie sicher, dass die Option "flacher Klon" für die github pullrequest Builder-Jobs in Ordnung ist?

Ich frage mich, wie github den Build-Job auswählt, den es für neue PRs verwendet. Warum werden die elektra-test-bindings und elektra-ini-mergerequests nie für eine neue PR ausgewählt? Warum ist es manchmal elektra-mergerequests-instabil und manchmal elektra-mergerequests(-stabil)?

@manuelm hast du eine idee?

Übrigens. irgendwie ist die kommunikation fertiger buildjobs und github stark beeinträchtigt (auch bei elektra-test-bindings). Auf fast jedem Build steht jetzt "Einige Überprüfungen sind noch nicht abgeschlossen".

Ein Nachteil der Konfiguration von elektra-test-bindings ist, dass sie nur Polling durchführt und ziemlich lange dauert, bis sie mit dem Aufbau beginnt (bis zu 5 min).

Und das ist ein Problem, weil? Der Test dauert sowieso länger als 5 Minuten.

Warum werden die elektra-test-bindings und elektra-ini-mergerequests nie für eine neue PR ausgewählt?

Warum sollte es? elektra-test-bindings wird nur durch die "Trigger-Phrase" ausgelöst. Keine Ahnung was elektra-ini-mergerequests ist.

Warum ist es manchmal elektra-merger-requests-instabil und manchmal elektra-merger-requests-stabil?

Die -stable/-unstable sind neu? Ich bin mir nicht sicher, ob es möglich ist, mehrere Jobs pro neuer PR auszulösen. Ich würde Nebenjobs machen.

Übrigens, ich habe das schon ein paar Mal gesagt, aber ich denke, die Menge an Jobs wird lächerlich und ein Zeichen für eine durcheinandergebrachte Konfiguration. Aber Kritik ist immer einfacher als etwas zu lösen.

Die 5 Minuten sind ein Problem, wenn Sie den Build-Server debuggen möchten. Und ich hoffe immer noch, dass wir irgendwann einen schnellen ersten Test bekommen, der etwa 5 min dauert.

Ahh, ok, ich habe die Option "Triggerphrase nur für Build-Triggering verwenden" übersehen. Die Konfiguration für den Github-Request-Builder ist wirklich ein Durcheinander.

Jemand sprach über Github-Projekte, bei denen mehrere Jobs für jede PR laufen. (Individuell angezeigt)

Was ist ein Nebenjob? Meinst du

Jemand sprach über Github-Projekte, bei denen mehrere Jobs für jede PR laufen. (Individuell angezeigt)

Sie müssen zwei Dienste auf github hinzufügen.

Was ist ein Nebenjob? Meinst du Multijob?

Ja Multijob.

Übrigens, was ist mit https://docs.travis-ci.com/ ? Travis unterstützt OSX.

Ich weiß, dass es Jenkins nicht ersetzen wird, aber möglicherweise den PR / bei jedem Commit-Build ersetzen. Jenkins kann immer noch mehrere Compiler/etc..-Tests durchführen.
Edit: Travis hat sogar gcc + clang.

Zugegeben, es wäre interessant, ihre CPU-Leistung / Strom kostenlos zu nutzen, da elektra Open Source ist.

Es ist wahrscheinlich, dass die Verbindung zwischen Github und Jenkins tatsächlich 1:1 ist. Im github-Dienst habe ich http://build.libelektra.org :8080/github-webhook/ eingegeben und keine Möglichkeit gefunden, in Jenkins eine andere URL zu erstellen. (Ich habe nur eine Möglichkeit gefunden, eine Überschreibung anzugeben, aber dadurch wurde keine neue URL erstellt).

In https://github.com/janinko/ghprb/issues/142 diskutieren sie, dass es "einfach funktionieren" soll? (Ohne mehrere Dienste hinzuzufügen)

Das sha1-Problem sollte jedoch jetzt gelöst sein. Es wurde beschädigt, weil Jenkins eine neue Sicherheitsmaßnahme eingeführt hat, die unbekannte Umgebungsvariablen bereinigt. Ich reparierte es wie vorgeschlagen (hinzugefügt -Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit, ghprbActualCommitAuthor, ghprbActualCommitAuthorEmail, ghprbAuthorRepoGitUrl, ghprbCommentBody, ghprbCredentialsId, ghprbGhRepository, ghprbPullAuthorEmail, ghprbPullAuthorLogin, ghprbPullAuthorLoginMention, ghprbPullDescription, ghprbPullId, ghprbPullLink, ghprbPullLongDescription, ghprbPullTitle, ghprbSourceBranch, ghprbTargetBranch, ghprbTriggerAuthor,ghprbTriggerAuthorEmail,ghprbTriggerAuthorLogin,ghprbTriggerAuthorLoginMention,GIT_BRANCH,sha1 in /etc/default/jenkins).

Über die Verwendung zusätzlicher Build-Server: Ja, fahren Sie fort. Es löst auch das Problem mehrerer Build-Jobs für eine einzelne PR ;) Ich habe travis-ci nie verwendet, kann also nichts dazu sagen. Ich habe die Erlaubnis erteilt, dass travis Zugang zu ElektraInitiative hat.

Erster Travis-Build: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Ich denke, wir brauchen eine yaml-Datei, damit Travis weiß, was zu tun ist.

Und ich habe herausgefunden, wie man mehrere Jenkins-Jobs pro PR erledigt. Für jeden Build-Job war ein anderer Kontext erforderlich. Im nächsten Meeting besprechen wir, was die "schnellen" und anderen Baujobs machen sollen.

Ich arbeite an Travis (oder checke ein paar Dinge aus)

Spaß haben. Travis hat auch einen Github-Dienst hinzugefügt, daher denke ich, dass auch eine PR mit travis erstellt wird.

Ich fluche schon laut

-- JNI konnte NICHT gefunden werden (fehlt: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
-- Plugin jni ausschließen, weil jni nicht gefunden wurde

Ich kann das Java-Plugin nicht richtig konfigurieren. Java-Bindungen funktionieren jedoch. Auf debian instabil. Irgendwelche Ideen? Ein Blick auf das cmake-Modul hilft nicht viel.

Bearbeiten: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h und /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h ist vorhanden

Bearbeiten 2: Verstanden. JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

https://travis-ci.org/manuelm/libelektra/builds/130638376

Debian unstable in einem Docker-Container gebaut. Aber Bauen dauert ewig.
Irgendwelche guten Ideen?

clang ist in Bezug auf die Build-Zeit oft schneller, aber ich denke, die Installation der Abhängigkeiten nimmt viel Zeit in Anspruch

Gibt es nicht ein minimaleres Debian-Docker-Image als das verwendete? Es scheint, dass viele Pakete installiert werden, die nicht benötigt werden.

@sirblackheart Was lässt dich das denken? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm wahrscheinlich das dist-upgrade. Viele Pakete werden aktualisiert, die Desktop-spezifisch sind, wie Wayland

Nein. Dist-Upgrade ist kurz. vielleicht eine Minute. Etwa 50 % der Zeit wird für die Installation der Build-Deps benötigt.

Ich verschiebe das Build-Image gerade an hub.docker.com. Hoffe das wird die Sache beschleunigen. Aber das Bild hat 1,9 GB

Verstrichene Zeit 14 Min. 8 Sek.

Ich bin mir nicht sicher, ob wir es viel besser machen können

wie gesagt, klingeln bringt uns vielleicht 2-3 minuten. Zumindest für das Aseprite-Projekt
https://travis-ci.org/aseprite/aseprite

Es wäre sowieso sinnvoll, beide Compiler zu haben.

Hatte gerade eine Idee beim Vorbereiten von Arbeitsmaterial: Was wäre, wenn wir die Pfade aller Commits im Push-Request extrahieren und Bindings/Plugins nur bauen, wenn sie betroffen sind? z.B

• Änderung in cmake/* löst alles aus (Plugins + Bindings)
• Änderung in src/bindings/foo löst Bindungsfoo aus
• Änderung in src/plugins/foo löst Plugin foo . aus
• Änderung in allem kompiliert keine Plugins + Bindungen

Wir haben immer noch den täglichen/zweimal täglich vollen Build auf Jenkins.

@manuelm gute Idee, @tom-wa würde so ein Skript schreiben, kannst du dafür ein neues Thema erstellen?

@mpranj :

@markus2330 jetzt verstehe ich den Docker-Ansatz von @manuelm, Travis wird Ubuntu 16.04 bis nächstes Jahr nicht unterstützen, also wird Docker benötigt, um alle Abhängigkeiten zu erhalten, die Ubuntu 14.04 nicht hat = swig3.0 libsystemd-devel.

Es tut mir leid, dass ich heute nicht an der Besprechung teilnehmen konnte. Auf der Arbeit bereiten wir heute noch einen großen Software-Rollout vor, deshalb kann ich das Büro nicht verlassen. Aber innerhalb kurzer Zeit kann ich E-Mails beantworten.

Ich habe vor 2 Tagen begonnen, OS X-Builds für Travis hinzuzufügen: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
Build ist hier: https://travis-ci.org/manuelm/libelektra/builds/130898079
Öffne die Dinge hier:

• [ ] cryto_openssl kann nicht kompiliert werden
• [ ] Bindungstests schlagen fehl
• [ ] kein Java

Ich freue mich, wenn jemand meine Arbeit von hier aus übernimmt. Ich habe kein OS X und das Warten darauf, dass Travis das OSX-System überprüft, summiert sich sehr schnell.

Re: Docker: Ja, die Standard-Ubuntu-Version von Travis funktioniert nicht gut. Sogar cmake ist zu alt.
Das Abrufen des hochgeladenen Docker-Image dauert nur etwa 3 Minuten. Und das Hinzufügen weiterer Bilder ist ein Kinderspiel. Ich denke, das ist eine gute Möglichkeit, alle Fallstricke zu umgehen, die die Standard-Travis-Linux-Umgebung hat (oder nach einem Update haben könnte).

Ich habe keine gute Möglichkeit gefunden, die verschiedenen Build- und Testphasen von libelektra (cmake + make + make test) mit docker (build + run) + travis (before_install, before_script, script) zu integrieren. Docker-Container werden nach Abschluss des Befehls beendet. Da Docker-Container zum Wegwerfen gedacht sind, können Sie danach nicht wieder aufnehmen. Ihr Festplatten-/Kompilierungsstatus ist also verschwunden, es sei denn, Sie mounten ein lokales Verzeichnis in den Container. Werde nächste Woche weiter an Docker arbeiten.

@manuelm Toll, du bist weiter gekommen als wir dachten. Mac OS X für PRs und per Commit wäre wirklich toll. Viele Leute verwenden jetzt Mac OS X und ich möchte ihnen den Build nicht immer wieder unterbrechen. In der heutigen Besprechung sagte

Nein, da die travis-Datei nachträglich noch modifiziert werden muss. Andernfalls wird nur OS X erstellt. Ich würde es lieber vorziehen, wenn @mpranj meine travis-Datei aufnimmt und die verbleibenden OSX-bezogenen Probleme behebt. Ich nehme dann seine Travis-Datei, wandele sie in einen Matrix-Build um und integriere die Linux/Docker-Builds + #730 (sofern bis dahin verfügbar)

PS: Bitte führen Sie Travis-Tests in einem Repository mit Benutzernamenabstand durch. Du wirst viele Pushs machen :-)

mingw64 baut auf PR auf, sollte funktionieren. Entschuldigung für die Verspätung. Ich schaue mir heute Travis an!

Gibt es einen Nachteil beim Aktivieren von Build-Jobs mit einer Phrase in einer PR (mit dem Github PR-Builder)?

Ich möchte die Jobs von #745 konfigurieren, damit ich testen kann, ob ich es behoben habe, aber ich kann es auf die meisten / (alle) Build-Jobs anwenden.

EDIT: Ich möchte lieber nicht alle Jobs automatisch starten, wir haben schon einige.

Ich denke, es ist eine gute Idee, wenn wir jeden Job so konfigurieren können, dass er mit einer Phrase ausgelöst wird. Ich denke, es gibt einen kleinen Nachteil (zumindest bei elektra-test-bindings): Man muss angeben, für welchen Zweig man bauen möchte und kann nicht einfach auf "Job jetzt bauen" drücken. Wäre super wenn du dafür eine Lösung findest.

Und Sie haben Recht, wir sollten lieber die automatischen Jobs abbauen.

Es gibt eigentlich eine ganz einfache Lösung. Wir verwenden die (env)Variable sha1 um PRs zu erstellen. Bei parametrisierten Builds werden Sie zur Eingabe des Werts aufgefordert, unabhängig davon, ob ein Standardwert festgelegt ist oder nicht.

Lösung: Setzen Sie die env-Variable sha1 auf master (in der Jenkins-Konfiguration selbst) und deaktivieren Sie parametrisierte Builds. Wenn es keine Einwände gegen das Setzen der Variablen gibt, würde dies genau das lösen, was Sie oben @markus2330 erwähnt haben.

Ich habe es bereits eingestellt, so dass Sie diese Build-Schaltfläche auf zB elektra-mergerequests drücken können und es beginnt mit dem Baumeister.

Ja, das ist eine sehr gute Lösung, gefällt mir. Es würde uns auch ermöglichen, einen Release-Zweig mit einem einzigen Switch zu erstellen (falls wir einen in Zukunft benötigen). Bis dahin ist "master" immer die richtige Wahl, wenn er nicht aus einem PR heraus ausgeführt wird.

Ich denke, es würde auch das Problem der gefilterten Umgebungsvariablen lösen, das wir früher hatten.

Dann können wir auch darüber nachdenken, die Build-Jobs zu reduzieren (keine Duplizierung für -mergerequest-Bulid-Jobs) und ein neues konsistentes Namensschema. (Vorschläge können hier gemacht werden.) Es könnte ein offenes Problem geben: Derzeit erstellen wir Coverage, Doku,... sowohl für PRs als auch für Master und kopieren sie an separate Orte. Wenn wir die Build-Jobs zusammenführen, brauchen wir eine Möglichkeit, innerhalb der Job-Master/PR-Jobs zu unterscheiden, um Coverage, Doku an verschiedene Stellen zu kopieren.

Ich bin fast fertig damit, dies auf alle Jobs anzuwenden (aber der Server wurde _nur_ wirklich langsam).
Gilt nicht für Jobs, die Wildcards erstellen ** (doc und einige andere, aber sehr wenige)

Sie können Build-Jobs jederzeit stoppen, wenn Sie daran arbeiten möchten, wenn Sie sie später neu starten (außer in der Veröffentlichungszeit). Normalerweise ist Jenkins selbst der Grund für die Verlangsamung der Maschine. Im Moment könnte ein rsync aus einem Backup das Problem sein, aber es ist dringend.

Ja, überhaupt kein Problem, es sollte getan werden, aber ich werde ein paar letzte Kontrollen machen.

Die Neuigkeiten @ElektraInitiative/elektradevelopers:

• wie gesagt fast _alles_ kann jetzt aus PRs gebaut werden und/oder nur auf den Build-Button drücken
• die Triggerphrasen sind immer der Jobname ohne das Präfix elektra- . (zB elektra-clang: jenkins build clang bitte) Ich habe jenkins build please und andere alte Phrasen aus Legacy-Gründen nicht geändert
• Die github-Build-Statusmeldung ist immer genau der Name des Build-Jobs

Danke, gut gemacht! Bitte aktualisieren Sie doc/GIT.md, damit jeder weiß, welche Sätze jetzt funktionieren.

(Ich hoffe, das @mention funktioniert nur für eine einzelne Nachricht und nicht jeder liest jede Nachricht, die wir hier schreiben)

Mac OS X für xcode 6.1 Build scheint defekt zu sein:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

Ich habe einen Umbau für diesen ausgelöst, aber es scheint mir ein vorübergehender Travis-Fehler zu sein.

Können Sie dokumentieren, wie ein Build für eine PR erneut ausgelöst wird? Ich wusste nicht, dass es möglich ist.

Direkt auf travis-ci.org über Ihren obigen Link:

Ich bezweifle, dass dies dokumentenwürdig ist, aber ich kann es trotzdem.
Der Build funktioniert immer noch nicht allein wegen des Git-Checkouts. Ich glaube nicht, dass das unsere Schuld ist.

Ah. Ich denke, Sie haben es zusammengeführt, bevor der Build ausgelöst / gestartet wurde.
Wenn ich andere zuvor erfolgreiche PRs umbaue, ist es auch kaputt.

Dies ist eher ein Travis-Problem als alles andere.

Okay, danke für die Untersuchung.

@manuelm debian -stable-mm scheint nicht erreichbar zu sein (sowohl für Jenkins als auch für mich vom TU-Netzwerk). Könnten Sie bitte nachforschen?

Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Removed slice User and Session Slice.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Graphical Interface.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Multi-User System.
etc..

Sieht aus, als hätte jemand den Container angehalten. Ich habe es wieder angefangen.

btw, ab morgen früh bin ich bis zum 1. August außer Haus. Per E-Mail bin ich weiterhin erreichbar, rechne aber mit einer kurzen Verzögerung.

Vielen Dank für die schnelle Lösung! Ich nehme an, Sie werden auch bei den nächsten Treffen nicht hier sein.

Ja

Einige Jobs haben den Fehler:

Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.

zB http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

Es könnte durch ein Jenkins-Update oder @KurtMi verursacht werden , das den kdb_import_man Zweig erstellt hat?

Hinweis an mich selbst: cppcms muss installiert werden.

Entschuldigung für die Branche, ich habe eine PR direkt auf der Github-Seite gemacht.

Ist es auf diese Weise einfacher, PRs zu erstellen? Bietet github nicht an, den Branch nach dem Zusammenführen zu löschen?

Die Veränderung war so minimal, dass ich faul wurde. Für sehr kleine Fixes ja, aber anscheinend wird der Branch danach nicht gelöscht. Ich habe keinen Löschzweig nach dem Zusammenführen gesehen.

Ich denke, der instabile Build ist kaputt:

Cloning the remote Git repository
Cloning repository git://github.com/ElektraInitiative/libelektra.git
 > git init /home/jenkins/workspace/workspace/elektra-mergerequests-unstable # timeout=10
Fetching upstream changes from git://github.com/ElektraInitiative/libelektra.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: The remote end hung up unexpectedly

Vollständiges Protokoll

@KurtMi instabil funktioniert wieder (bei den meisten Builds), aber der Walk-Fehler bleibt bei einigen der einfacheren Build-Jobs bestehen. Es scheint, als ob der Zweig noch irgendwo verfügbar ist, vielleicht in einem Cache auf den Build-Servern?

 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/* --depth=1
Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.
org.eclipse.jgit.errors.RevWalkException: Walk failure.

@mpranj Vielleicht sollten wir mehr Skripte in der Quelle hinzufügen, dies würde einfachere Updates für jeden Build-Job ermöglichen. In #806 haben wir noch einen weiteren Fehler mit Leerzeichen im Build-Verzeichnis gefunden, also sollten wir global (für jeden Build-Job) Leerzeichen im Build-Verzeichnis hinzufügen. Ich würde es vorziehen, wenn wir ein Skript jenkins-setup hinzufügen könnten, das einige nützliche Variablen exportiert (wie export HOME="$WORKSPACE/user space ) und dies tut

mkdir "build space"
cd "build space"

Außerdem sollten wir Build-Jobs erstellen, die ein globales Repo aktualisieren. Einzelaufgaben siehe oben.

Das Global Repo könnte definitiv dazu beitragen, die Bandbreite zu reduzieren. Build-Skripte in-Source könnten auch eine gute Idee sein, zumindest würden sie von git verfolgt.

Ich bin kein Fan von Leerzeichen in Pfaden, aber sicher.

schnelles build in passwd defekt?

Der schnelle Build-Job ist nervig, ich versuche kdberrors.h bei jedem Build zu entfernen und schaue, ob es dann reibungsloser funktioniert. Auf lange Sicht ist der @manuelm- Vorschlag in #730 die beste Lösung: Wir sollten einfach überprüfen, wie die Quelle aktualisiert wurde, und basierend darauf entsprechende Messungen

Ich denke, #894 behebt auch den schnellen Build, ich werde die Zeile auskommentieren, in der kdberrors.h entfernt wird.

Einige Jobs sind unterbrochen, zum Beispiel der HTML-Doc-Job.

@mpranj Hast du Zeit, es dir anzuschauen?

@markus2330 Fertig. Die verbleibenden Buildfehler scheinen nicht mit dem Buildsystem zu tun zu haben.

@mpranj Danke! Was hast du getan, um es zu beheben? Ich fände es sinnvoll, wenn wir hier auch Lösungen für Serverprobleme sammeln.

Ich habe in "Quellcodeverwaltung" > "Git" geändert
"Branchenspezifizierer"-Wert "**" zu "${sha1}"

Das verwenden wir auch in den anderen Jobs. Dies ermöglicht es, den Build per Schaltfläche (Branch-Standardeinstellung auf Master) oder per github PR Builder (sha1 of commit) auszulösen.

Ich erinnere mich, dass ich die ENV-Variable "sha1" einmal auf "master" gesetzt habe. Es scheint jetzt zu fehlen, aber die Jobs funktionieren gut, also ignorieren wir das.

Ich denke, wir könnten die Builds viel schneller machen, wenn wir Objektbibliotheken häufiger verwenden. Viele Objektdateien werden mehrfach kompiliert. Wir müssten nur sicherstellen, dass die Kompilierungsflags für jeden Ort, an dem wir die Objektbibliotheken verwenden, gleich sind, aber ich denke, dies sollte leicht möglich sein.

Ein Beispiel, bei dem es einen großen Unterschied machen könnte, ist meiner Meinung nach KDB.

@Namoshek Bitte

Jenkins wurde auf 2.7 aktualisiert, alle Plugins aktualisiert, empfohlene Plugins wurden hinzugefügt:

• Pipeline (Installation scheint fehlgeschlagen zu sein?)
• Plugin für GitHub-Organisationsordner

und einige Plugins deinstalliert:

• Zweig-API
• CVS/SVN (scheint nicht mehr zwingend erforderlich)

Außerdem wurde ruby-dev auf jedem Agenten installiert.

Ich habe die "Aktuellen Probleme" im oberen Beitrag aktualisiert. Es wäre wichtig, dass Elektra auch ohne installierte Abhängigkeiten kompiliert, daher sollten wir dies mit Build-Server-Agenten überprüfen, die keine Abhängigkeiten installiert haben (außer cmake und build-essential). FreeBSD- und OpenBSD-Build-Agenten sind jedoch auch wichtig ;)

@mpranj Haben Sie eine Ahnung, was mit elektra-multiconfig-gcc47-cmake-options nicht stimmt? Sie haben überall "fatal: reference is not a tree:"-Fehler. Der Job hat "sha1" in seiner Konfiguration?

Ich habe die Multiconfig unabhängig von konkreten Compilern gemacht (es gibt genug andere Build-Jobs für bestimmte Compiler), damit sie auf jedem Agenten laufen können.

@markus2330 Keine Ahnung. Ich habe nichts geändert und nur:

• manuell einen Build vom Master ausgelöst
• einen Build von github ausgelöst

Beide Builds konnten den Baum überprüfen und mit dem Bauen beginnen.
Also: Ich kann es nicht reproduzieren.

Eine Idee: travis hatte Probleme, wenn es eine PR gab und Sie sie zusammenführen, bevor travis den Klon machen konnte. Vielleicht ist etwas Ähnliches mit elektra-multiconfig-gcc47-cmake-options passiert, da ein Build dort ~3 Stunden dauert.

Das Pushen von Artefakten auf doc.libelektra.org funktioniert wieder, Jenkins und Plugins wurden aktualisiert.

Ich habe die neue Build-Server-URL https://build.libelektra.org in den Webhooks von Github aktualisiert. Hoffentlich werden also die nächsten PRs wieder gebaut.

Jenkins Haus ist fast voll. Es scheint auch keine PRs zu bauen.

Jenkins Haus ist fast voll.

Danke, ich habe die Größe geändert.

Es scheint auch keine PRs zu bauen.

Hast du eine Idee, was hier falsch sein könnte? Manuelles Auslösen scheint zu funktionieren?

Veröffentlichung von Doku in doc.libelektra. org:12025 für die Builds fehlgeschlagen. Ich habe den SSH-Server (auf dem build-homepage-Agenten) neu gestartet und es scheint wieder zu funktionieren.

Der vserver für *.libelektra.org scheint nicht erreichbar zu sein. Ich habe es bei hetzner gemeldet.

Der Grund für das Herunterfahren der Netzwerkverbindung vom Container war, dass libelektra.org kompromittiert wurde. Siehe Nr. 1505 für weitere Informationen.

Es wäre großartig, wenn wir ein git-build-Paket für Stretch hinzufügen könnten, es tauchen immer mehr Stellen auf, an denen wir Debian-Pakete benötigen würden, die für Stretch gebaut wurden.

@BernhardDenner hast du den oberen Beitrag durchgesehen? Gibt es etwas, das Sie leicht tun können? Gibt es etwas, das @mpranj bei der zukünftigen Verbesserung von Build-Server-Jobs

Auf Wunsch von @sanssecours habe ich elektra-mergerequests (vorübergehend) deaktiviert, damit PRs nicht immer einen falschen Fehler bekommen. Außerdem habe ich für @KurtMi . hinzugefügt

jenkins baut gcc-configure-debian-optimizations bitte

@KurtMi Wenn Sie Änderungen am Build-Job benötigen, ändern Sie einfach scripts/configure-debian-optimizations

@sanssecours hat nun auch Zugriff auf den Build-Server.

Übrigens. Sie können Jobs stornieren, wenn sie ohnehin von anderen Jobs abgelöst werden (derzeit hohe Auslastung). Achten Sie nur darauf, dass Sie keine Jobs für aktive PRs abbrechen, sonst wird die PR nicht grün. (Es sei denn, Sie starten sie mit dem Satz "jenkins build ... please" neu.)

@sanssecours Jenkins wurde (zum zweiten Mal) neu gestartet. Könnten Sie bitte hier dokumentieren, ob Sie neue Plugins installieren. (Updates müssen nicht dokumentiert werden).

Hier können auch Neustartanfragen gestellt werden.

Ich habe "Ruhezeit" von 2 auf 5 geändert, um mehr Zeit zum Zusammenführen mehrerer PRs und/oder zum Pushen verschiedener Commits zu haben, ohne wiederholt neu aufzubauen.

Außerdem habe ich das Issue #1689 geöffnet, das Timeouts in Builds beschreibt (ich habe es hier wegen langer Fehlermeldungen nicht hinzugefügt).

Ich habe auch einige obsolete Aufgaben oben in den neuen Abschnitt "Veraltete/irrelevante Probleme [Grund]:" verschoben.

Ich habe die Plugins auf dem Build-Server aktualisiert. Hoffentlich beheben die Updates die Probleme, die wir in PR #1698 und PR #1692 haben.

@markus2330 Können Sie bitte den Build-Server neu starten?

Ich habe Jenkins von 2.73.2 auf 2.73.3 aktualisiert und Jenkins neu gestartet.

Hoffentlich beheben die Updates die Probleme, die wir in PR #1698 und PR #1692 haben.

Könnte es sich um ein allgemeines Problem handeln, das nicht mit diesen beiden PRs zusammenhängt? Hoffentlich ist es jetzt behoben.

Sieht so aus, als wäre JENKINS_HOME fast voll 😢.

@markus2330 👋 Könnten Sie bitte

• bereinige das Home-Verzeichnis oder sag mir, wie ich das machen kann,
• Jenkins und alle veralteten Plugins aktualisieren?

Danke, dass du mich angepingt hast!

Scheint, als hätte ein Plugin eine "Sicherheitslücke beim Lesen beliebiger Dateien", nämlich das "Script Security Plugin 1.35".

Ich habe alle Plugins aktualisiert und auch Jenkins von 2.73.3 auf 2.89.1 aktualisiert.

Außerdem habe ich die Größe der Festplatte von 20 GB auf 50 GB geändert.

Wir sollten den Server bald neu starten, es gibt einige nicht neu gestartete Prozesse, die von Bibliotheks-Upgrades betroffen sein könnten, die im Moment möglicherweise unsicher sind (jedoch nichts mit Jenkins zu tun haben). @BernhardDenner Können Sie den Neustart durchführen (und die Korrekturen durchführen, wenn etwas nicht startet)?

Bitte zögern Sie nicht, alles zu melden, was ich während dieser Upgrades kaputt gemacht habe.

Der Server hatte Last 20 und reagierte kaum. Wir müssen mit "jenkins build all please" vorsichtig sein und sollten die Agenten längerfristig vom Hauptserver entfernen.

Ich habe auf Jenkins 2.89.2 aktualisiert und den Server neu gestartet. Ich melde mich wenn alles wieder läuft.

Anscheinend werden jetzt alle Agenten mit dem Fehler "Der Server-Hostschlüssel wurde vom Verifier-Callback nicht akzeptiert" getrennt.

@BernhardDenner Ich habe gesehen, dass Puppet

Ich habe erfolglos versucht, ein Downgrade auf 2.89.1 und 2.73.3 durchzuführen: Die Verbindung zu Agenten funktioniert immer noch nicht.

Ein großes Dankeschön an @BernhardDenner, der das ssh-Problem behoben hat.

Wir sollten aufhören, Jenkins zu aktualisieren, ohne die Versionshinweise zu lesen, es scheint, dass selbst die stabilen Updates zu viele Dinge kaputt machen. (Die sind nicht einmal durch Downgrade rückgängig zu machen!)

Ich muss einen großen Engpass beim Build-Server melden.
elektra-multiconfig-gcc47-cmake-options dauert 14 Stunden und die
elektra-multiconfig-gcc-stable dauert
Ich bin mir nicht sicher, ob das ein neues Verhalten ist und ich bin mir bewusst, dass es sich bei diesen Jobs nicht um einen einzelnen Build-Job handelt, aber dieser Engpass sollte nicht unbemerkt bleiben.

Vielen Dank für die Berichterstattung. Die Idee war, Teiljobs dieser Jobs auf die Ryzen-Hardware zu verteilen, leider hatte niemand Zeit für das Setup. Bei Interesse bitte Kontakt mit mir aufnehmen.

a7.complang.tuwien.ac.at (ryzen) scheint abgestürzt zu sein. Ich habe das Problem gemeldet. Unser Admin wird den Computer hoffentlich am Montag neu starten.

Ich habe das Inkremental vorübergehend deaktiviert (seltsamer Fehler, siehe #1784), der Admin hat den Ryzen-Server neu gestartet und dann Jenkins neu gestartet (weil Jenkins keine Verbindung zu Ryzen herstellen konnte und es einen riesigen Rückstand an Ryzen-Builds gab).

ryzen funktioniert nun wieder und baut das Backlog auf.

Die Idee war, Teiljobs dieser Jobs auf die Ryzen-Hardware zu verteilen

@markus2330 Mir ist aufgefallen, dass es in den Konfigurationsmatrixeinstellungen des Multiconfig-Jobs eine Option namens Run each configuration sequentially . Vielleicht wird es automatisch verteilt, wenn wir dies einfach deaktivieren, damit es mehrere Konfigurationsoptionen gleichzeitig erstellt, oder haben Sie dies bereits versucht?

Nein, ich habe es noch nicht probiert, probiere es bitte aus.

@markus2330 nach der Build-Server-Warteschlange zu urteilen, scheint dies der Trick zu sein, ich werde es zusätzlich auf gcc-stable anwenden, nachdem es für gcc-stable-multiconfig funktioniert hat

Mir ist jedoch aufgefallen, dass der Ryzen diese Aufgaben nicht zu bewältigen scheint. Ich denke, das liegt daran, dass es so konfiguriert ist, dass es nur Jobs verarbeitet, die seinen Tags entsprechen, und die Multiconfig-Builds diese Tags auf den ersten Blick nicht richtig setzen. Also sollten wir entweder Ryzen alles Mögliche ausführen lassen oder mehr Tags für die Build-Jobs setzen. Es sieht so aus, als würde Ryzen keine Jobs verarbeiten, für die überhaupt kein Tag festgelegt ist.

Ich werde es zusätzlich auf gcc-stable anwenden, nachdem es für gcc-stable-multiconfig funktioniert hat

Dankeschön!

Mir ist jedoch aufgefallen, dass der Ryzen diese Aufgaben nicht zu bewältigen scheint.

Nein, tut es nicht, aber es führt bereits eine Reihe anderer Jobs aus. Aber vielleicht können wir dazu v2 machen?

Ich werde es zusätzlich auf gcc-stable anwenden

getan

Aber vielleicht können wir dazu v2 machen?

Ich habe die v2 konfiguriert und warte jetzt nur noch darauf, dass die #1806 PR zusammengeführt wird, damit ich mehr Builds als eine zulassen kann. Ich dachte, dass 8 Jobs dafür in Ordnung sein sollten, da es ein 8-Core ist, mit -j 2, um auch den SMT zu nutzen?

Um den build-v2-Container neu zu starten, falls v2 abstürzt oder neu gestartet wird, geben Sie einfach ein. Beachten Sie, dass dies nur möglich ist, wenn der Container bereits erstellt wurde - folgen Sie doc/docker/jenkinsnode/README.md für diese Anweisungen. Verwenden Sie dann diesen Befehl, um neu zu starten, nachdem der Container erstellt wurde, aber gestoppt wurde:

docker start build-v2

Um die ssh-Verbindung des neuen Build-Knotens von der v2 über die a7 an die Außenwelt weiterzuleiten, habe ich auf der a7 folgenden ssh-Tunnel eingerichtet (der Docker-Container ordnet seinen ssh-Port auf der v2 auf 22222 zu):

ssh -L 0.0.0.0:22222:localhost:22222 <username>@v2.complang.tuwien.ac.at

Außerdem ändert sich der öffentliche ssh-Schlüssel des Docker-Containers bei jedem Image-Neuaufbau und muss daher auch im Build-Server angepasst werden. Dies ist nicht erforderlich, wenn der Container nur neu gestartet wird. Um dies herauszufinden, geben Sie auf der v2 Folgendes ein:

sudo docker exec -it build-v2 bash
# now you should be on the docker machine
cat /etc/ssh/ssh_host_ecdsa_key.pub
> ecdsa-sha2-nistp256 <blablablalb> <root@6b906cc01f23>

Kopieren Sie nur die ersten beiden Dinge, also den Schlüsselalgorithmus und den Schlüssel selbst, kopieren Sie diese Benutzerinformationen nicht am Ende in die Konfiguration von ryzen-v2 in jenkins für den ssh-Schlüssel!

v2 ist down, informierte ich den Admin. Es ist ziemlich seltsam: a7 und v2 sind beide komplett neue Hardware und die Vorfälle sind ziemlich häufig.

v2 scheint zurück zu sein und ich habe den Build-Container dort neu gestartet. Hoffentlich haben wir jetzt wieder schnellere Builds. Außerdem habe ich elektra-haskell zu "jenkins build all please" hinzugefügt, da ich stabile Haskell-Builds für meinen Typechecker haben möchte, daher ist das Testen eine gute Ergänzung.

Außerdem möchte ich hier anmerken, dass wir zusätzlich einen weiteren Build-Knoten erstellen wollen, der sich um die mm-Builds kümmert, die nun auch der neue Flaschenhals auf der v2 zu sein scheinen.

Zuletzt @markus2330 Ich denke, der Point Run Bashism Checker ist bereits fertig, da dies einer unserer üblichen Tests ist /testscr_check_bashisms.sh .

Alle Knoten für das Label debian-jessie-homepage||homepage und den Build-Agenten debian-wheezy-mr sind derzeit offline. Das Neustarten der Build-Agenten funktioniert nicht. Es wäre wirklich nett, wenn jemand mit SSH oder physischem Zugriff auf diese Knoten dieses Problem untersuchen könnte.

Ich habe die vservers neu gestartet, aber das Neustarten der Agenten in Jenkins hat nicht mit dem Fehler "Kein gültiger Krümel wurde in der Anfrage enthalten" funktioniert. @BernhardDenner Hast du eine Idee?

Scheint, als ob v2 auch down ist. Wir haben also 3 nicht-funktionale Agenten 😢

v2 ist zurück, aber ich frage mich, warum es immer ausfällt? Könnte es mit unserem Build-Prozess zusammenhängen?

In Bezug auf die "keine gültige Krume" habe ich das auch gesehen, als ich versucht habe, den Agenten auf v2 neu zu starten, aber als ich es einfach erneut versuchte, funktionierte es.

v2 ist zurück, aber ich frage mich, warum es immer ausfällt? Könnte es mit unserem Build-Prozess zusammenhängen?

Es scheint ein Kernel-/Hardwarefehler zu sein (nicht einmal sysreq funktioniert, wenn der Computer hängt). Unsere Nutzung könnte den Fehler auslösen. Der Computer lief mehrere Monate fehlerfrei und seit wir ihn benutzen, ist er bereits dreimal abgestürzt.

Ich habe den Kernel aktualisiert und den X-Server bereinigt.

In Bezug auf die "keine gültige Krume" habe ich das auch gesehen, als ich versucht habe, den Agenten auf v2 neu zu starten, aber als ich es einfach erneut versuchte, funktionierte es.

Dankeschön! Nun konnte ich den Homepage-Agenten wieder starten.

Außerdem habe ich den Agenten debian-jessie-minimal und seinen Build-Job deaktiviert. Wir sollten Docker-Container für minimale Jobs erstellen, das habe ich als Aufgabe hinzugefügt.

Wie wir gestern überrascht waren, war der Community-Server ausgefallen, weil er abgestürzt ist und ein falscher ARP-Cache unsere IPs auf andere Server umgeleitet hat. Nach dem Neustart hat alles wieder funktioniert, aber die Raid-Synchronisierung läuft noch. (Es könnte wegen der hohen Last so langsam sein.)

Der Community-Server hat eine nahezu konstante Auslastung von 10. Momentan sind es 13,20 11,29 9,35. Wir sollten die Jobs, die direkt auf dem Community-Server laufen, wirklich reduzieren und die Last auf v1 verlagern. Irgendwelche Freiwilligen?

Es gibt ein Upgrade von Jenkins von 2.89.2 auf 2.89.4. Leider habe ich keine einfache Möglichkeit gefunden, das Changelog anzuzeigen ( apt-get changelog schlägt fehl, da es sich um ein inoffizielles Paket handelt). Gibt es Gründe, dieses Update nicht durchzuführen?

Das Upstream-Changelog befindet sich unter https://jenkins.io/changelog-stable/
Anscheinend enthält 2.89.4 Sicherheitsfixes.

Danke fürs Nachschlagen!

Ich habe auf Jenkins 2.89.4 aktualisiert und alles läuft wieder.

elektrahomepage wurde nach Neustarts standardmäßig nicht gestartet, das habe ich geändert (/etc/vservers/elektrahomepage/apps/init/mark=default).

Ich habe auch den Test-Docker-Build-Job aktiviert.

v2 ist wieder down :cry:

Aber zumindest scheint a7 jetzt stabil zu sein.

Ich habe clang-format-5.0 auf a7 und auf dem Stretch-Knoten (debian-stretch-mr) installiert.

Für die nächsten PRs bitte nach clang-format-5.0 umformatieren.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ wurde vorübergehend deaktiviert.

Wir untersuchen derzeit v2. UEFI ist vom 6.6.17. Es scheint, als ob die Abstürze immer am Wochenende passierten, vielleicht gibt es zu dieser Zeit eine höhere Belastung? Ich werde versuchen, das Setup von v1 auf v2 zu replizieren.

v1 und v2 laufen mit demselben Kernel.

@e1528532 scheint, als ob Ihre SSH-Bridge nicht gestartet wurde und der Befehl in doc/docker/jenkinsnode/README.md mit "Kontext kann nicht vorbereitet werden: Symlinks im Dockerfile-Pfad kann nicht ausgewertet werden: lstat /root/Dockerfile: no such file or directory" fehlschlägt " und dann "Bild 'buildelektra- stretch:latest ' kann lokal nicht gefunden werden". Dies bedeutet, dass v2 im Moment nicht erreichbar ist.

@markus2330 hat geschrieben: Problem nach #1829 verschoben

Ich denke, eines der neuesten Updates für den Build-Server hat elektra-gcc-configure-debian-stretch kaputt gemacht, das keine Verbindung mehr zum Repository herstellen kann:

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not known)

.

Ich denke, das Problem mit elektra-gcc-configure-debian-stretch ist der Build-Server ryzen , der keine Verbindung zu GitHub herstellen kann. Ich habe das Label für den Build-Job entsprechend von debian in debian-stretch-mr geändert. Jetzt scheint der Build-Job wieder

ryzen, der keine Verbindung zu GitHub herstellen kann

Scheint, als hätte der NetworkManager-Fix unseres Administrators mit "manged=true" nicht zuverlässig funktioniert. Nach Neustart "/etc/resolv.conf" war wieder ein baumelnder Symlink. Ich habe es wieder behoben, GitHub sollte von Ryzen aus erreichbar sein. rzyen v2 ist leider immer noch nicht erreichbar (ssh bridge fehlt).

Elektra 0.8.22 wird endlich veröffentlicht. Ich füge den Link zu #676 hinzu, sobald die Website erstellt wurde. Die Erstellung der Website dauert mehr als eine Stunde. Vielleicht können wir den Homepage-Build auf einen schnelleren Computer verschieben und nur die resultierende Website an ihren Speicherort kopieren.

Ich denke, wir müssen etwas gegen den Server unternehmen, der http://build.libelektra.org hostet wenige Minuten, um überhaupt eine Verbindung zum Server herzustellen, wenn wir überhaupt eine Verbindung zum Server herstellen können:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em><a href="/jenkins/">GET&nbsp;/jenkins/</a></em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.10 (Debian) Server at build.libelektra.org Port 443</address>
</body></html>

.

Ja, betroffen ist nicht nur Jenkins, sondern alles andere, was auf diesem Server läuft. Für mich ist die Situation oft auch inakzeptabel. Anscheinend ist zu wenig RAM vorhanden. (2GiG-Swap wird verwendet)

Jenkins könnte der Grund sein, es gibt Dutzende von Java-Prozessen, die die Liste in htop anführen. Lange Zeit hatten wir genug RAM und Swap wurde kaum genutzt, und wir haben nicht viel verändert (außer Jenkins Upgrade und Erhöhung der Anzahl der Build-Jobs).

Ich schlage vor, den Community-Server überhaupt nicht mehr als Agent zu verwenden. Dafür bräuchten wir v2 zurück, aber @e1528532 scheint beschäftigt zu sein. Wir könnten auch einen besseren Server mieten, aber dann bräuchten wir jemanden, der Zeit für die Migration hat.

@markus2330 Können Sie bitte den Build-Server neu starten? Derzeit scheitern sogar einfache Jobs wie elektra-todo .

ich habe die v2 am sonntag neu gestartet, aber anscheinend ist sie schon wieder heruntergefahren, also sollten wir v2 zuerst stabil machen, bevor wir darüber nachdenken, andere dinge darauf zu installieren.

Ich habe Jenkins neu gestartet und v2. Jenkins scheint wieder reibungslos zu laufen.

@e1528532 Der

Daher sollten wir zuerst v2 stabil machen, bevor wir darüber nachdenken, andere Dinge darauf zu legen.

Die Hauptausfallzeit wurde durch die SSH-Brücke verursacht. Wenn v2 Probleme hatte, wurde es normalerweise innerhalb eines Tages neu gestartet.
Ich habe jetzt den Rest des X-Servers entfernt, daher hoffe ich, dass v2 jetzt auch stabil ist. Für a7 schien dies der Trick zu sein (es war lange kein Neustart nötig). Ohne Last auf v2 (was die SSH-Bridge erfordert) wissen wir jedoch nicht, ob es stabil ist.

Wie wäre es, Diskussionen über Hardware (Neustarts) und Software (Jenkins-Upgrades) aufzuteilen?

Es scheint ein Problem mit der Netzwerkverbindung zwischen a7 und v2 zu geben. v2 ist betriebsbereit, aber ich erhalte immer noch "Keine Route zum Host". Anscheinend kann ich es heute nicht reparieren.

Das Netzwerk von v2 war ausgefallen, weil bei der Deinstallation von GNOME auch der Netzwerkmanager deinstalliert wurde. Wir haben jetzt das Netzwerk repariert (mit /etc/network/interfaces) und auf das neueste BIOS/UEFI aktualisiert. Hoffentlich ist jetzt alles stabil.

Übrigens. Es gibt noch eine Hardware, die wir über eine SSH-Brücke verwenden könnten ... (PCS)

Der SSH-Tunnel scheint immer noch nicht zu funktionieren. Auch nach einem Neustart von a7 ist keine Verbindung zu v2 möglich.

Ja, das war nicht automatisiert. Jetzt habe ich mich um alles gekümmert. Der Docker-Container sollte jetzt automatisch neu gestartet werden, wenn der Computer neu gestartet wird. Zumindest habe ich das Flag --restart gemäß https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode auf "always" gesetzt

Außerdem habe ich einen neuen Benutzer namens "ssh-tunnel-a7-v2" erstellt, der weder für a7 noch für v2 ein Passwort festgelegt hat (also die Passwort-Authentifizierung für diesen deaktiviert). Ich habe ein ssh-Zertifikat für den Benutzer auf dem a7 erstellt und den öffentlichen Schlüssel davon zu den bekannten Hosts auf v2 hinzugefügt. Dann habe ich einen systemd-Dienst zu /etc/systemd/system/ssh-tunnel-a7-v2.service hinzugefügt, der den ssh-Tunnel automatisch als systemd-Dienst gemäß https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service öffnet. Daher sollte es auch funktionieren, wenn der Server neu gestartet wird oder die ssh-Verbindung abstürzt und nicht mehr von mir oder meinem Benutzer abhängen. Durch die Verwendung eines Zertifikats müssen für Verbindungen keine Passwörter verwendet werden.

Darüber hinaus wird v2 natürlich mit dieser neuen automatischen Konfiguration neu gestartet. Hoffentlich überlebt es den nächsten Crash (falls es einen gibt), theoretisch sollte es aber mal sehen.

Der Build-Job test-docker schlägt immer fehl, wenn Jenkins den Job auf ryzen v2 ausführt:

docker inspect -f . elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: docker: not found
[Pipeline] sh
[test-docker] Running shell script
+ docker pull elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: docker: not found

. Ich wollte den Job auf andere Knoten als ryzen v2 , aber anscheinend fehlt die Option für diesen Schritt auf der Konfigurationsseite von test-docker . Könnte bitte jemand nachschauen und dieses Problem beheben?

Vielen Dank, dass Sie sich damit befasst haben! Ist es nicht möglich, den Agenten mehrere Labels zuzuweisen? Dann könnten Sie Ryzen v2 ein eindeutiges Label zuweisen und den Job daran binden.

Zum Glück bekommen wir bald Support für unseren Build-Server :+1:

Ist es nicht möglich, den Agenten mehrere Labels zuzuweisen?

Soweit ich weiß, ist es möglich, einem Agenten mehrere Labels zuzuweisen.

Dann könnten Sie Ryzen v2 ein eindeutiges Label zuweisen und den Job daran binden.

Wie ich bereits erwähnt habe [[1]] scheint die Option „Einschränken, wo dieses Projekt ausgeführt werden kann“ zu fehlen:

Ich wollte den Job auf andere Knoten als ryzen v2 , aber anscheinend fehlt die Option für diesen Schritt auf der Konfigurationsseite von test-docker .

.

Ahh, ich habe Ihre Aussage missverstanden als: "Es gibt keine Möglichkeit, einen booleschen Ausdruck zu schreiben, der es mir erlaubt, (stable && !ryzenv2)" zu sagen, nicht dass es überhaupt keine Option für die Agentenbeschränkung gibt.

Vielleicht kann dies durch das DSL erfolgen. Ich werde Lukas fragen, ob er weiß, was zu tun ist.

Hi,

wie @sanssecours bemerkte, hat ryzen v2 kein Docker installiert, aber das Docker-Tag.
test-docker-Ausführungen erfordern, dass Knoten das Docker-Tag aufweisen.

Mögliche Lösungen sind, entweder Docker auf dem Knoten zu installieren oder das Tag in Jenkins vom Knoten zu entfernen

Mögliche Lösungen sind, entweder Docker auf dem Knoten zu installieren oder das Tag in Jenkins vom Knoten zu entfernen

Vielen Dank für die Bereitstellung einer Lösung für das Problem. Ich habe gerade das docker Tag von ryzen v2 . Soweit ich das beurteilen kann scheint jetzt alles zu funktionieren.

Ich habe die Beschreibung des Knotens „ryzen v2“ aktualisiert, um widerzuspiegeln, dass es sich tatsächlich „nur“ um einen Docker-Container handelt, der auf v2 ausgeführt wird. Daher war Docker nicht verfügbar, obwohl es auf v2 installiert ist.

Außerdem wurde ein Plugin zu Jenkins hinzugefügt, das eine einfachere Visualisierung von Build-Daten ermöglicht (nicht in jeden Build klicken zu müssen)

v2 ist wieder down, ich habe es gemeldet.

Ich habe v2 neu gestartet, konnte den Agenten jedoch nicht erneut verbinden.

Immerhin haben wir endlich Fehlermeldungen bekommen, was vor dem Absturz passiert ist (natürlich gibt es keine Garantie, dass die Fehlermeldungen etwas mit dem Absturz zu tun haben):

watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [docker-containe:789]
...
NMI watchdog: Watchdog detected hard LOCKUP on cpu 14
...

Seltsam, es sieht so aus, als ob meine Neustartmaschinerie funktioniert hat, sowohl der SSH-Tunnel als auch die Docker-Knoten wurden neu gestartet und ich kann eine Verbindung zu a7.complang.tuwien.ac.at -p 22222 herstellen, was bedeutet, dass alles geöffnet sein sollte. Aber irgendwie zeigen mir Jenkins aus irgendeinem Grund nur ein unendliches Spinnrad, kein Timeout, kein nichts.

Ich habe meine manuelle SSH-Bridge wie zuvor ausprobiert, das gleiche. Den Docker-Container noch einmal neu gestartet, das gleiche. Also ehrlich gesagt bin ich mir nicht sicher, was jetzt ohne Fehlermeldung genau los ist, das einzige, was ich gefunden habe, ist ein Typ, der anscheinend einen ähnlichen Fehler hat (Drehrad, aber keine Meldung), aber keine Lösung dafür außer dem Neustart des gesamten Master-Jenkins Knoten (den ich nicht ausprobiert habe): https://issues.jenkins-ci.org/browse/JENKINS-19465

BEARBEITEN: Ich habe eine der vorgeschlagenen Problemumgehungen ausprobiert (Hostnamen-Konfiguration auf etwas zurücksetzen, das nicht existiert, erneut verbinden, dann erkennt Jenkins, dass der Hostname falsch ist, ändere wieder den tatsächlichen Hostnamen, dann funktionierte es plötzlich ohne weitere Probleme). Ich denke, dieser Fehler ist anstelle von etwas mit meinem Neustart-Setup aufgetreten, aber warten wir auf den nächsten Absturz, um sicher zu sein;)

@markus2330 Ich wette, du hast das schon selbst herausgefunden, aber eine https://bugzilla.kernel.org/show_bug.cgi?id=196683 , es gibt einige Vorschläge Abhilfen dafür

Scheint so, als ob der Build-Server ryzen keine Verbindung zu unserem Repository herstellen kann :

Fehler beim Abrufen von https://github.com/ElektraInitiative/libelektra.git

.

die DNS-Konfiguration baumelte wieder. Da ich nicht ganz verstehe warum es so ist
Setup so wie es derzeit ist Ich habe nur die Nameserver-Einstellungen wiederhergestellt und
startete den Docker-Build-Job neu.

Am 12. März 2018 um 17:03 schrieb René Schwaiger [email protected] :

Scheint, als ob der Build-Server Ryzen keine Verbindung zu unserem Repository herstellen kann
https://build.libelektra.org/jenkins/job/test-docker/162/console :

Fehler beim Abrufen von https://github.com/ElektraInitiative/libelektra.git

.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

Da ich nicht ganz verstehe, warum es so eingerichtet ist, wie es derzeit ist

Ich fürchte, niemand versteht es. Möglicherweise ist der DNS-Server falsch konfiguriert und gibt keine korrekten Nameserver-Informationen an. Für v2 haben wir den Netzwerkmanager deinstalliert und es scheint, als ob die resolv.conf dort jetzt stabil ist. Eine Möglichkeit besteht also darin, den Netzwerkmanager auch auf dem a7 zu deinstallieren. (und benutze /etc/network/interfaces) Es gibt keinen Grund dafür, dass v2 und a7 unterschiedliche Setups haben, es liegt nur an der schlampigen Verwaltung.

Im Idealfall (auf lange Sicht) verwalten wir beides mit Puppet.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , dafür gibt es einige Vorschläge zur Problemumgehung

C6 sollte deaktiviert werden, aber wir werden die Untersuchung fortsetzen.

Der neue Build-Agent "ryzen v2 docker" scheint keinen D-Bus-Daemon zu haben, der wie "debian-stable-mm" läuft.

Kann jemand es bitte entweder installieren/starten oder mir sagen, welches Skript die multiconfig-gcc47-cmake-options-Builds konfiguriert, damit ich ein Snippet hinzufügen kann, um sicherzustellen, dass es gestartet wird?

@markus2330 Ich vermute, da sowohl ifupdown als auch networkmanager aktiviert sind, geraten sie beide in die Haare. Das Deaktivieren eines der beiden würde sicherlich helfen.

Okay, ich habe Gnome und Network-Manager auf a7 entfernt, um mit v2 konsistent zu sein.

Der neue Build-Agent "ryzen v2 docker" scheint keinen D-Bus-Daemon zu haben, der wie "debian-stable-mm" läuft.

Der Build-Agent lebt in einem Docker-Container, hoffentlich kann @ingwinlu oder @e1528532 Ihnen helfen, den dbus-Daemon dort zu starten.

Dankeschön. Es sollte ziemlich einfach sein. Ich starte es im Docker-Container (Ubuntu 17.10 kunstvoll gebaut aus docs/docker/Dockerfile ) mit den folgenden Befehlen:

mkdir /var/run/dbus # create directory for pidfiles & co
dbus-daemon --system

Der Buildserver ryzen kann sich nicht mehr mit unserem Repository verbinden 😭.

Entschuldigung, das war mein Fehler. Scheint, als hätte das Stoppen des Netzwerkmanagers ausgereicht, um das System zu zerstören.

Es sollte jetzt behoben sein. Bitte zögern Sie nicht, weitere Probleme zu melden.

@markus2330 ziemlich sicher, dass es beim nächsten Neustart wieder kaputt

Ich habe mir erlaubt, die Datei /etc/network/interfaces zu wiederholen (und die Konfiguration der Schnittstellen nach /etc/network/interfaces.d zu verschieben)
das in Kombination mit der Deinstallation des Netzwerkmanagers sollte es hoffentlich stabil halten

Bitte überprüfen Sie die Konfiguration und lösen Sie möglicherweise einen Neustart aus, um zu sehen, ob es funktioniert hat

@ingwinlu Vielen Dank für die

Ich habe festgestellt, dass ich zu viele Pakete entfernt habe, also habe ich Java (openjdk 9 headless und default-jre) erneut installiert :smile:

@ingwinlu Könnten Sie dbus bitte auf dem v2-Agenten ausführen? Idealerweise verschieben Sie auch "/home/armin/buildelektra-stretch/Dockerfile" an ein nicht benutzerspezifisches Ziel.

@markus2330 mein Vorschlag für das weitere Vorgehen mit der Build-Umgebung sieht tatsächlich vor, den aktuellen dockercontainer-on-v2-Knoten zu entfernen und ihn durch einen docker-fähigen Knoten zu ersetzen (dh nicht mehr auf einen Docker-Container in v2, sondern direkt auf v2) .

Danach können wir die Build-Pipeline einrichten, um das Image selbst aus Dockerfiles zu erstellen, die in das Repository eingecheckt wurden, um die verschiedenen Umgebungen bereitzustellen, die für Tests benötigt werden.

Ich kann den Rollout eines dbus-fähigen Docker-Image priorisieren, wenn ich dazu komme, aber ich möchte keine Arbeit machen, die bald irrelevant wird, wenn ich nicht muss.

Ja, das macht Sinn!

Das längerfristige Ziel von v2 ist, dass wir es mit einigen anderen Docker-Containern teilen müssen (nicht für Elektra), daher wäre es eine gute Sache, wenn alle unsere Teile so virtualisiert sind, dass sie die anderen Docker-Container nicht beeinflussen können. (vielleicht rekursives Docker oder Xen?) Wir könnten/sollten dasselbe für a7 tun, um identische Setups zu haben.

Wir werden weiterhin direkten Zugriff auf die Maschinen haben, aber wir sollten jedes Risiko reduzieren, dass Jenkins Docker-Maschinen töten kann, mit denen es nichts zu tun hat.

Für einige Agenten haben wir bereits ein Puppet-Setup. Es wäre toll, wenn wir es nicht umgehen oder noch besser: dieses Setup für a7 und v2 erweitern. Ich hoffe @BernhardDenner kann dir bald mehr Infos dazu geben.

Der Buildserver ist wieder down 🙌.

Übrigens könnten wir die Diskussion über den Build-Server-Status in eine GitHub-Team-Diskussion verschieben , da dieses Thema möglicherweise nicht für alle Personen interessant ist, die dieses Thema abonniert haben.

Ja, der gesamte Server ist ausgefallen, einschließlich des Build-Servers :cry: Und v2 ist auch ausgefallen (unabhängig davon). Ich habe v2 neu gestartet und die C-States-Option in UEFI geändert. Aber es scheint, als ob es ein großes Problem mit unserem Server gibt. Hoffentlich bekommen wir es durch bessere Hardware mit mehr Speicher ersetzt :crossed_fingers:

Diskussion im GitHub-Team

Wird nicht jeder von ElektraDevelopers benachrichtigt, wenn wir etwas in der GitHub-Teamdiskussion schreiben? Hier in dieser Ausgabe kann jeder entscheiden, ob er/sie abonnieren möchte.

Für mich ist eine immer noch offene Frage, ob wir dieses Problem in zwei Themen aufteilen sollten: Hardwarebezogen und Jenkins-bezogen.

Wird nicht jeder von ElektraDevelopers benachrichtigt, wenn wir etwas in der GitHub-Teamdiskussion schreiben?

Soweit ich das beurteilen kann, ja.

Hier in dieser Ausgabe kann jeder entscheiden, ob er/sie abonnieren möchte.

Das gilt auch für Teamdiskussionen .

Build-Server ist wieder aktiv. Einstellungen geändert:

• xms- und xmx-Einstellungen, um die Menge der Garbage Collection zu reduzieren, wenn viele Builds in der Warteschlange stehen
• Mir ist aufgefallen, dass wir SCM-Abfragen verwenden. Ich habe den Poller auf 4 gleichzeitige Umfragen global gleichzeitig gedrosselt, um hoffentlich die Spitzen, die der Server derzeit bekommt, ein wenig zu reduzieren.

BEARBEITEN:

* Setzen Sie die Anzahl der Builds auf 30 für alle Pipelines, da diese laut mehreren Quellen beim Zugriff auf die Webui gelesen werden und somit eine große Anzahl alter Builds Anfragen verlangsamt

Aktualisieren Sie Jenkins auf Ver. 2.107.1

• Jenkins War-Datei aktualisieren
• Deaktivieren Sie die Use browser for metadata download Plugin-Sicherheitseinstellung, da diese keine Aktualisierung von Plugins zulassen würde
• Aktualisieren Sie Plugins auf die neuesten verfügbaren Versionen

BEARBEITEN 2018-03-18:

• Allen Knoten, die auf mm . laufen, wurde ein zweiter Executor hinzugefügt

* Alle Agenten, die auf mr . laufen, wurden depriorisiert

Der Master sollte jetzt unter Last viel reaktionsschneller sein. Build all sollte näher an 2h liegen als an den 4h+ von zuvor.

BEARBEITEN 24.03.2018:
Entschuldigung für die Verzögerungen, arbeitsreiche Woche...

• Dem Jenkinsserver (elektra-jenkinsfile) wurde ein neuer Job hinzugefügt, der das im Repository gefundene Jenkinsfile ausführt (sobald es existiert)

BEARBEITEN 28.03.2018:

• Die Tunnel-Unit-Datei wurde überarbeitet, jetzt analysiert sie Umgebungsdateien und kann daher so angepasst werden, dass sie auf mehrere Ziele zeigt
• v2-Server als Slave hinzugefügt, der Docker ausführen kann
  
  
  
  • Jenkins-Benutzer auf v2 hinzugefügt
  
  
  • installiert openjdk-9 auf v2
  
  

BEARBEITEN 29.03.2018:

• Ulimit-Einstellungen auf Jenkins Master korrigieren

Obwohl ich mir ziemlich sicher bin, dass @ingwinlu oder jemand bereits damit beschäftigt ist: Es scheint, als wäre ryzen v2 falsch konfiguriert:

FATAL: Could not apply tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <[email protected]>) not allowed

von https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console aber passiert bei mehreren Gelegenheiten.

Ups, tut mir Leid. Es hat keine Deps installiert und sollte nur als Docker-Host fungieren. Ich werde die zusätzlichen Flags entfernen.
//EDIT: sollte gemacht werden. das war hoffentlich genug
//EDIT2: Ich habe auch test-docker vorerst deaktiviert, da es offensichtlich die Build-Images nicht finden kann, die zum Ausführen der Tests erforderlich sind.

Aber verdammt schnell ist das Ding, wenn es tatsächlich etwas bekommt, das es bauen kann
//EDIT3: test-docker wurde so aktiviert, dass es nur auf Knoten mit docker-prefab-Tag läuft und gab dieses Tag an ryzen

Leider scheint das Problem größer zu sein als ursprünglich erwartet.

Einige Jobs haben ihre Knoten hartcodiert. Einige Tags sind veraltet (stabil auf Jessie-Knoten). Einige Jobs benötigten nicht die richtigen Knoten und wurden nur auf dem richtigen ausgeführt, weil sie dort schon einmal ausgeführt und erfolgreich gebaut wurden.

Die Einführung eines neuen Knotens (ryzen v2 native) hat die Zuweisung ein wenig durcheinander gebracht, obwohl dies nicht der Fall sein sollte.

Bitte erwarten Sie ein unerwartetes Verhalten, bis alles wieder läuft, wo es war.

Änderungsprotokoll:

• umbenannte Knoten, <os>-<hostname>-<buildenv>
• deaktiviert elektra-multiconfig-gcc47-cmake-options
  es läuft eigentlich schon seit geraumer Zeit nicht mehr auf gcc47-Slaves, mit einer Mischung aus gcc49- oder gcc63-Building, je nachdem, wo es geplant war. Wenn es reaktiviert wird, sollte es wahrscheinlich auf den gcc63-aktivierten Dockercontainer auf v2 gehen
• eine Menge Jobs neu markiert (vielleicht haben einige von ihnen verpasst)
  
  
  
  • elektra-todo benötigte stable , aber nicht alle stabilen Knoten hatten tatsächlich sloccount installiert
  
  
  • viele weitere ähnliche Fälle
  
  

A7 scheint down zu sein

waht [email protected] schrieb am Do., 29. März 2018, 21:24:

Obwohl ich mir ziemlich sicher bin @ingwinlu https://github.com/ingwinlu oder
jemand ist bereits dabei: Es scheint, als wäre Ryzen v2 falsch konfiguriert:

FATAL: Tag kann nicht angewendet werden jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Befehl "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" gab den Statuscode 128 zurück :
Standard:
stderr:
* Bitte sagen Sie mir, wer Sie sind.

Lauf

git config --global user.email " [email protected] "
git config --global user.name "Ihr Name"

um die Standardidentität Ihres Kontos festzulegen.
Lassen Sie --global weg, um die Identität nur in diesem Repository festzulegen.

fatal: leerer Ident-Name (für [email protected] ) nicht erlaubt

von
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console
ist aber mehrfach passiert.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

Willst du daran arbeiten? Ich könnte es heute neu starten. Als Alternative könnte unser Admin oder ich es am Dienstag neu starten.

Wenn es nicht zu mühsam ist. Sonst kann ich nicht an meiner PR arbeiten
Wochenende

markus2330 [email protected] schrieb am Sa., 31. März 2018, 14:33:

Willst du daran arbeiten? Ich könnte es heute neu starten. Als Alternative unsere
admin oder ich könnte es am Dienstag neu starten.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

Okay, ich habe es neu gestartet und auch den C6-State im BIOS/UEFI deaktiviert (war an aktiviert). Ich habe auch gnome/xorg entfernt (ich dachte, ich hätte das schon getan?).

Übrigens. Der Bildschirm war komplett schwarz, wir können also nur vermuten, was die Ursache war.

diese sind alle 10 Minuten oder so auf a7 aufgetaucht:

Apr 04 07:14:23 a7 kernel: [Hardware Error]: Corrected error, no action required.
Apr 04 07:14:23 a7 kernel: [Hardware Error]: CPU:0 (17:1:1) MC15_STATUS[Over|CE|MiscV|-|AddrV|-|-|SyndV|-|CECC]: 0xdc
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Error Addr: 0x00000003705a2f00
Apr 04 07:14:23 a7 kernel: [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x0000015c0a400f03
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Extended Error Code: 0
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Error: DRAM ECC error.
Apr 04 07:14:23 a7 kernel: EDAC MC0: 1 CE on mc#0csrow#3channel#0 (csrow:3 channel:0 page:0x700b45 offset:0xf00 grain
Apr 04 07:14:23 a7 kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
lines 5977-6036/6036 (END)

Dies könnten die Gründe für die Ausfallzeit des a7 sowie einige der seltsamen Build-Verhalten bei a7 neuerdings sein

Der Valgrind-Abschnitt in elektra-ini-mergerequests wurde deaktiviert, da er über make run_memcheck

diese tauchen alle 10 Minuten oder so auf a7 auf

Ja, wir haben sie schon gesehen. Beim Kauf des Computers wurde tatsächlich überprüft, ob ECC funktioniert und damals traten keine derartigen Fehler auf. Hängt die Häufigkeit dieser Fehler irgendwie von der Auslastung des Systems ab?

Deaktivierter Valgrind-Abschnitt in elektra-ini-mergerequests, da er über make run_memcheck ausgeführt wurde

Danke, dass du das aufgeräumt hast.

Ich habe zufällige Outtakes (Container stürzen ab, Builds stoppen mittendrin, Verbindungsabbrüche, ...) auf a7 ohne wieder "echte" Logs. nur die bereits erwähnten Speicherkorrekturen.

Danke, scheint etwas nicht in Ordnung zu sein. Und wir haben jetzt auch nicht korrigierbare Fehler:

Apr  5 09:50:40 a7 kernel: [39549.503787] mce: Uncorrected hardware memory error in user-access at 73d6ce880
Apr  5 09:50:40 a7 kernel: [39549.503794] [Hardware Error]: Uncorrected, software restartable error.
Apr  5 09:50:40 a7 kernel: [39549.505882] [Hardware Error]: CPU:2 (17:1:1) MC0_STATUS[-|UE|MiscV|-|AddrV|-|Poison|-|-|UECC]: 0xbc002800000c0135
Apr  5 09:50:40 a7 kernel: [39549.506581] [Hardware Error]: Error Addr: 0x000000073d6ce880
Apr  5 09:50:40 a7 kernel: [39549.507287] [Hardware Error]: IPID: 0x000000b000000000
Apr  5 09:50:40 a7 kernel: [39549.507980] [Hardware Error]: Load Store Unit Extended Error Code: 12
Apr  5 09:50:40 a7 kernel: [39549.508677] [Hardware Error]: Load Store Unit Error: DC data error type 1 (poison consumption).
Apr  5 09:50:40 a7 kernel: [39549.509378] [Hardware Error]: cache level: L1, tx: DATA, mem-tx: DRD
Apr  5 09:50:40 a7 kernel: [39549.510136] Memory failure: 0x73d6ce: Killing java:1470 due to hardware memory corruption
Apr  5 09:50:40 a7 kernel: [39549.510908] Memory failure: 0x73d6ce: recovery action for dirty LRU page: Recovered

da geht wieder a7.

an einer produktiveren Front: Ich habe das Blue Ocean- Frontend für Jenkins installiert. Vorschau

da geht wieder a7.

Es ist wirklich frustrierend. Ich habe die Maschine neu gestartet und die Agenten wieder verbunden. Ich werde unseren Administrator bitten, morgen den RAM zu ersetzen, also rechne morgen mit Ausfallzeiten.

an einer produktiveren Front: Ich habe das Blue Ocean-Frontend für Jenkins installiert. Vorschau

Sieht großartig aus! Vielleicht kannst du es uns beim nächsten Treffen zeigen?

Unser Admin ist schon am Wochenende. Ich starte a7 neu und setze BIOS/UEFI auf Werkseinstellungen zurück. Sollten die Fehler über das Wochenende andauern, wird er hoffentlich den Arbeitsspeicher austauschen.

BEARBEITEN: Es wurde kein Build-Job ausgeführt, daher wurde kein Build-Job abgebrochen.

EDIT: Alles ist wieder oben. Bisher keine Speicherfehler.

Sieht viel besser aus. Hat jemand zu viel Linus-Tech-Tipps gesehen und den Server übertaktet?

Entschuldigung, ich musste Jenkins für einige Zeit stoppen. Der Server hatte Last 20 und Dinge, die ich tun musste, waren nicht mehr möglich (>1h Wartezeit, dann gab ich auf und stoppte Jenkins).

Ist es möglich, dass auch nicht gestartete Build-Jobs RAM benötigen? (die Warteschlangenliste war sehr lang) Ansonsten sind die lokalen Build-Jobs der beste Kandidat für diese Probleme. (3 lokale Build-Jobs liefen)

@ingwinlu Idealerweise bauen wir nichts auf diesem Server. Darüber hinaus können wir Build-Jobs von der Auslastung eines Servers abhängig machen. (Auf einem Server mit Last > 5 keine Jobs starten?).

Ich habe alles wieder angefangen, aber ich hoffe, dass wir dafür eine schnelle Lösung finden.

Ich habe die VERSION und CMPVERSION in den Jenkins-Systemeinstellungen gepumpt.

@ingwinlu Es wäre toll, wenn wir diese Einstellungen auch in Jenkinsfile hätten.

@markus2330 siehe 8de9272051fe903a7df08f0abdf18879701f7ac9 für ein Beispiel, wie dies in einem Jenkinsfile erreicht wird

make run_memcheck von den folgenden Zielen entfernt, da sie seit einiger Zeit versagen und dank #1882 endlich im Build-System auftauchen

• gcc-configure-debian-stretch-minimal
• gcc-configure-debian-wheezy
• elektra-gcc-i386

Beschränken Sie elektra-gcc-configure-debian-stretch auf die Ausführung auf Knoten: stretch && !mr

Jenkins Master auf ver. 2.107.2 aktualisieren + alle Plugins aktualisieren

Ich habe heute versucht, allowMembersOfWhitelistedOrgsAsAdmin zu allen Build-Jobs hinzuzufügen, aber anscheinend kann ich immer noch keinen Build All (siehe # 1863) richtig auslösen und nur einige Jobs werden ausgeführt

@markus2330 https://github.com/janinko/ghprb/issues/416#issuecomment -266254688

Kann jemand bitte

• Fix
• deaktivieren, oder
• (noch besser) löschen

elektra-clang-asan bitte . Derzeit schlägt der Build-Job fehl, obwohl alle fehlgeschlagenen Tests:

• testlib_notification
• testshell_markdown_base64
• testshell_markdown_ini
• testshell_markdown_mini
• testshell_markdown_tcl
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

Funktioniert bei Travis einwandfrei .

Sie testen nicht dasselbe, da sie (zum Beispiel) verschiedene Clang-Versionen verwenden ...

Da dieser Thread für Fehlerberichte oder längere Diskussionen absolut unauffindbar ist, werde ich neue Themen für clang und clang-asan eröffnen, sobald ich dazu komme.

Sie testen nicht dasselbe, da sie (zum Beispiel) verschiedene Clang-Versionen verwenden ...

Ich stimme zu, während Travis das veraltete clang 5.0.0 , ist die Clang-Version auf elektra-clang-asan uralt ( 3.8.1 ). Ich sehe den Wert eines ASAN-aktivierten Build-Jobs für einen so alten Compiler nicht.

Ich habe #1919 für den fehlgeschlagenen "testlib_notification"-Test auf "elektra-clang-asan" erstellt.

Ich habe einen Build mit allen deaktivierten mr-Agenten getestet, und der Master reagierte perfekt, während ein Build mit allen aktivierten mr-Agenten tatsächlich einige der Builds ausschaltete. Daher wird #1866 definitiv eine Verbesserung bringen, wenn wir alle mr-Agenten loswerden können (-keuchend, da nicht containerisierbar)

Weitere Tests zeigen, dass so ziemlich nur die Homepage erstellt wird. Ich habe es vorerst aus build all damit es nur explizit ausgeführt wird.

Es wird durch eine containerisierte Lösung ersetzt.

v2 ist mit dem neusten BIOS wieder online.

Bitte melden Sie alle Segfaults hier (die CPU könnte fehlerhaft sein).

a7 scheint unten zu sein?

Am 4. Mai 2018 um 11:10 Uhr schrieb markus2330 [email protected] :

v2 ist mit dem neusten BIOS wieder online.

Bitte melden Sie alle Segfaults hier (die CPU könnte fehlerhaft sein).

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 ist mit dem neuesten BIOS wieder online

a7 wieder runter?

Ja, es war abgestürzt. Es zeigte den Login-Prompt ohne Fehlermeldung und keinerlei Reaktion auf Eingaben (einschließlich sys-req). Nur Hardreset hat geholfen.

Wenn Sie eine Idee haben, was das Problem sein könnte, sagen Sie es bitte.

Leider ist auf a7 kein persistentes Journal eingerichtet, also keine Protokolle

wann können wir erwarten, dass a7 und v2 wieder verfügbar sind?

Ohh, ich wusste nicht, dass sie unten waren. Ich werde unseren Admin bitten, neu zu starten, und wenn er nicht in der Lage ist, werde ich es gegen 17:00 tun.

Edit: Er sagte, er wird sie sofort zurücksetzen.

Edit: Sie sind beide wieder oben.

Ich habe heute a7 und v2 manuell neu gestartet. v2 scheint nicht mehr erreichbar zu sein. Kannst du bitte, dass es tatsächlich läuft?

//EDIT: gelöst durch Festlegen der Netzwerkkonfiguration auf beiden Computern

anscheinend ist a7 wieder untergegangen.

Ok, ich starte sie neu. Sonst werden wir diese Veröffentlichung nie fertig bekommen.

irgendein Hinweis auf die Ursache? nur Netzwerkprobleme oder reagierte die Maschine wieder nicht?

Alles sollte jetzt lauffähig sein.

Ich habe es gerade im richtigen Moment bekommen, es gab einige Protokolle, bis es schließlich vollständig eingefroren ist.

Die Protokolle waren:

INFO: rcu_sched detected stalls on CPUs/tasks:
...
rcu_sched kthread starved for 7770 jiffies
watchdog: BUG soft lockup - CPU#2 stuck for 22s! [docker-gen]
... (many repetitions)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 2

Das kann alles sein. Von der defekten Ryzen-CPU zu einem schlechten Netzteil :(

Am 12. Mai 2018 um 14:33 Uhr schrieb markus2330 [email protected] :

Alles sollte jetzt lauffähig sein.

Ich habe es gerade im richtigen Moment bekommen, es gab einige Protokolle bis es endlich soweit war
komplett eingefroren.

Die Protokolle waren:

INFO: rcu_sched erkannte Blockaden auf CPUs/Tasks:
...
rcu_sched kthread hungerte nach 7770 Jiffies
Watchdog: BUG Soft-Lockup - CPU#2 bleibt für 22s hängen! [docker-gen]
... (viele Wiederholungen)
NMI-Watchdog: Watchdog erkannte hartes LOCKUP auf CPU 2

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

Über #1993

@ingwinlu Bitte deaktivieren Sie Jobs, wenn sie derzeit nicht erfolgreich sind (oder lösen Sie sie zumindest nicht standardmäßig oder mit "jenkins build all please") aus. Es sollte hohe Priorität haben, dass wir in PRs keine Jobs verpassen, bei denen eigentlich alles in Ordnung ist. (dass ein längeres Versagen keine gute Situation war)

Wenn sie aufgrund einer von Ihnen durchgeführten Jenkins-Aktion fehlschlagen, wäre es schön, die Jobs neu zu starten :heart: Das hier in #160 zu sagen ist auch in Ordnung.

v2 ist wieder da, mit neuer CPU!

Bitte viele Jobs zum Stresstest einreichen :smile:

a7 scheint wieder unten zu sein.

Danke, alles ist wieder oben.

Ich habe a7 neu gestartet.

Eine Schaltung zu haben, die a7 jede Stunde zurücksetzt, würde höchstwahrscheinlich die Verfügbarkeit erhöhen.

wann können wir a7 wieder online sehen?

a7 ist wieder online

v2 ist wieder online

Das Netzteil von v2 wird in ca. 1h getauscht.

@ingwinlu können Sie die Agenten deaktivieren und anschließend wieder aktivieren? (Wenn Sie gerade daran arbeiten.)

v2-Agenten sind vorerst deaktiviert

v2 läuft wieder. Es hat ein neues Netzteil. Bitte reichen Sie viele Jobs ein, um die Maschine einem Stresstest zu unterziehen.

Ich habe die Jenkins-Plugins aktualisiert. Der resultierende Neustart stellte teilweise alte Jenkins-Knoten wieder her (bevor sie umbenannt wurden), was überall zu kaputten Builds führte, da Git-Repositorys kaputt waren.

Ich habe betroffene Repositorys aufgeräumt und zwischengespeicherte Docker-Container bereinigt, um sicherzugehen.

a7 ist wieder down und daher sind Docker-basierte Builds nicht mehr verfügbar.

Ich fahre auch das Update auf xunit zurück, da es gegen Sicherheitsbeschränkungen verstößt.

Ich habe a7 neu gestartet und alle Agenten wieder angeschlossen.

Docker-Builds sind nicht verfügbar, da a7 wieder down ist.

Ich habe den Server neu gestartet und die Agenten wieder verbunden.

Ich denke, a7 zu ersetzen ist der beste Weg, siehe #2020

Ich denke, es ist wieder unten, mein letztes Commit führte zu Cannot contact a7-debian-stretch: java.lang.InterruptedException

@e1528532 Vielen Dank, dass Sie es hier geschrieben haben! Wer möchte, kann auch in #2020 abstimmen

Ich habe a7 neu gestartet und die Agenten wieder verbunden.
Hoffen wir das Beste, dass am Wochenende keine Probleme auftreten.

a7 ist wieder unten :cry: Überraschend, dass es fast das ganze Wochenende geklappt hat. Könnte der Uptime-Rekord der Woche sein. Trotzdem hat #2020 nicht viele Kommentare bekommen.

Ich habe a7 neu gestartet (es reagierte auf sysctl) und jemand anderes startete Jenkins. Alles läuft wieder.

a7 ging gerade wieder runter.

Danke für die Info! Ich habe a7 neu gestartet und die Agenten wieder verbunden.

Macht es Sinn, dass wir den Agenten "debian-jessie-minimal" haben? Ich denke, Sie können es sicher entfernen, sobald es in Docker integriert ist. (und es scheint schon so zu sein)

BEARBEITEN:
In https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
und https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
es gibt Warnungen:

WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask<strong i="13">@544b40e</strong>
java.lang.LinkageError
    at hudson.util.ProcessTree$UnixReflection.<clinit>(ProcessTree.java:710)
    ...
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
    at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854)

schlechte Nachrichten. v2 ging auch runter.

EDIT: aber ich scheine mich per ssh damit verbinden zu können....
EDIT2: Auf v2 wurde ein Neustart durchgeführt, aber jetzt kann ich keine Verbindung mehr herstellen. immer noch von a7 pingbar...

EDIT3: jetzt ist auch a7 unten.

Vielen Dank für die Meldung! Ich habe a7 und v2 neu gestartet. Wir sollten #2020 überdenken.

Ich glaube v2 ist wieder down:

Kann v2-debian-stretch nicht kontaktieren: java.lang.InterruptedException

Mit v2 war alles in Ordnung, aber a7 war wieder down. Alle Agenten sind jetzt wieder online.

v2 scheint wieder halb nicht zu reagieren. pingbar von a7, aber überhaupt keine ssh-Aktion. sollten die btrfs probleme allein von den sympthoms sein. Kannst du alles neu starten, bevor du übers Wochenende nach Hause fährst?

@ingwinlu Danke, @waht und ich haben v2 erfolgreich neu gestartet, aber ich kann die Agenten nicht verbinden ("Verbindung verweigert (Verbindung verweigert)"). Irgendeine Idee, was hier falsch ist? (interaktives SSH-Login funktioniert)

ssh funktionierte nur, wenn keine Verbindung über die Bridge hergestellt wurde.

nach Neustart des Bridging-Dienstes konnte die Verbindung aufgebaut werden.

Es scheint, als ob der SSH-Tunnel in einem seltsamen undefinierten Zustand gelandet ist und sich nicht selbst getötet hat. Nicht sicher, warum es sich nicht selbst beendet hat (serveraliveinterval ist aktiviert).

Ich musste auch alle Arbeitsbereiche auf v2 manuell bereinigen, da die fs beschädigt war und alle Build-Jobs darauf fehlschlugen.

a7 scheint unten zu sein. Ich bin mir nicht sicher, ob ich es vor Montag neu starten kann.

Ich habe a7 und v2 neu gestartet. (v2, weil es Fehlermeldungen auf a7 gab, dass es die ssh-Bridge nicht zu v2 erstellen kann. Aber auch nach Neustart von v2 traten die gleichen Fehlermeldungen auf. Trotzdem scheint die ssh-Bridge zu funktionieren. Vielleicht fehlt eine Abhängigkeit (Netzwerk?) in die Boot-Skripte von a7?)

Vielleicht fehlt eine Abhängigkeit (Netzwerk?) in den Boot-Skripten von a7

Nein es ist da.

es kann die ssh-Brücke zu v2 nicht erstellen

Ich glaube, dieses Verhalten tritt auf, wenn der v2-Kernel nicht mehr reagiert (und daher keine eingehenden Netzwerkverbindungen hergestellt werden können). In der Vergangenheit haben Sie Protokolle erwähnt, die auf Btrfs-Fehler in v2 hinweisen.

Ich bereite den Build-Server für einen Shutdown vor, um die CPU später zu ersetzen.

a7 und v2 sind wieder da (a7 mit neuer CPU, v2 mit überprüftem Root-Dateisystem)

während es während des Tages mithielt (mit konstantem Aufbau), scheint es, als ob a7 gerade wieder gefallen wäre.

Ja, ich starte morgen früh neu.

Wir sollten wieder über #2020 diskutieren.

Ich habe a7 neu gestartet. Es war wieder ein CPU-Hang.

a7 ist wieder unten.

Danke, ich habe es neu gestartet. Alle Agenten sind wieder online.

Es sieht so aus, als ob einige der Debian-Knoten ausgefallen sind und daher warten einige PRS schon lange darauf, dass die Testausführung beginnt. Ist das beabsichtigt?

Es sieht so aus, als ob einige der Debian-Knoten ausgefallen sind und daher warten einige PRS schon lange darauf, dass die Testausführung beginnt. Ist das beabsichtigt?

Während eines Upgrades auf dem mm-debian-unstable-Knoten reagierte die Maschine nicht mehr und wir konnten seitdem keine Verbindung mehr herstellen. Da der Besitzer nicht auf unsere E-Mails antwortet, wird es wahrscheinlich für immer verschwunden sein.

Während wir bereits eine große Anzahl von Build-Jobs auf das neue System portiert haben, fehlen diejenigen, die derzeit in der Warteschlange hängen.

Ich habe die betroffenen Jobs deaktiviert und als zu ersetzen markiert + aus den Dokumenten entfernt

@ingwinlu Vielen Dank, dass Sie sich darum gekümmert haben!

Das Lesen der xdg-Tests ist sehr wichtig, wenn jemand am Resolver arbeiten möchte. Ich habe es hier oben im Post hinzugefügt. Können Sie das, was Sie in der obigen Checkliste bereits erreicht haben, aktualisieren?

Dieses Mal ist v2 der glückliche Gewinner.

@markus2330 Ich habe den oberen Beitrag aufgeräumt.

Vielen Dank für das Aufräumen! Ich werde v2 (und vielleicht a7, mal sehen) morgen früh neu starten.

Ich habe es neu gestartet. Es gab keine Reaktion und keine Nachricht. Siehe #2020

Bitte starten Sie a7 und v2 neu.

Ich habe a7 neu gestartet. Ich habe kein Problem mit v2 gefunden, sollte ich es trotzdem neu starten?

i7 ist jetzt unter 192.168.173.96 verfügbar, kannst du bitte eine Brücke über a7 dazu erstellen?

Sie müssen einen ssh-tunnel-a7-v2-Benutzer auf dem Computer erstellen oder ein Konto für mich erstellen.

Wir haben einen zusätzlichen Build-Slave i7-debian-stretch hinzugefügt, der bei libelektra Buildjobs hilft.

v2-docker-buildelektra-stretch (offline) da dort keine weiteren Build-Jobs geplant sind. Die SSH-Brücke auf a7, die den Agenten verfügbar gemacht hat, wurde ebenfalls deaktiviert.

Hallo @ingwinlu ,
wie in der letzten Sitzung besprochen, bräuchte ich den Access Point.
Könnten Sie mir bitte die Informationen per E-Mail zusenden , meine E-Mail ist in
Übrigens. konnte Ihre E-Mail nirgendwo finden, vielleicht sollten Sie sich dieser Datei hinzufügen.

Unser v2-Build-Server wird bis 31.07. 09:00 offline sein, da wir Benchmarks darauf ausführen. Erwarten Sie längere Bauzeiten.

Entschuldigen Sie die Unannehmlichkeiten.

//EDIT: Ausfallzeit um 2 Stunden verlängert

Scheint so, als ob die Erweiterung jetzt auch bestanden hat. Wäre gut, die schnellen Builds nach dem Mittagessen (ca. 13:00 Uhr) wieder zu haben. :Lächeln:

mm-debian-unstable wurde aktualisiert und ist wieder online. Gibt es Jobs, die wir reaktivieren und an den Server anheften können?

Die Festplatte des i7 scheint voll zu sein. Meine Jobs schlagen mit No space left on device fehl ( Job und Job )

Das neue Build-Interface (Dockerization & Jenkinsfile) gefällt mir übrigens sehr gut. Sehr hilfreich zum Reproduzieren von Build-Fehlern.

Vielen Dank für die Meldung!

Leider würde eine Größenänderung einen Neustart erfordern (rootfs muss kleiner gemacht werden, bevor das andere erweitert werden könnte) und würde nur 20G bringen. Ich habe die Jenkins-Build-Ordner entfernt, aber sie waren winzig, also sind wir immer noch bei 99%.

Das Bereinigen von _docker wäre also effektiver:
@ingwinlu scheint sowohl _docker/overlay2 als riesig zu sein. Hast du eine Idee, warum all das Zeug dort gesammelt wurde?

Ich erzwinge bereinigte Docker-Artefakte mit docker system prune -fa . Dies
rund 190 GB Speicherplatz für Docker-Images bereinigt.

Am Mo, den 13. August 2018 um 07:54 Uhr schrieb markus2330 [email protected] :

Vielen Dank für die Meldung!

Leider würde eine Größenänderung einen Neustart erfordern (rootfs muss gemacht werden .)
kleiner, bevor die anderen erweitert werden konnten) und würde nur 20G bringen. ich
Die Jenkins-Build-Ordner wurden entfernt, aber sie waren winzig, also sind wir immer noch bei
99%.

Das Bereinigen von _docker wäre also effektiver:
@ingwinlu https://github.com/ingwinlu scheint beides zu sein _docker/overlay2
ist riesig. Hast du eine Idee, warum all das Zeug dort gesammelt wurde?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

Dankeschön!

Können wir das in libelektra-daily oder in einen Cronjob einfügen?

Daily tut etwas Ähnliches, aber weniger aggressiv. Muss noch einen nehmen
schau mal wenn ich wieder in Wien bin.

markus2330 [email protected] schrieb am Mo., 13. Aug. 2018, 09:22:

Dankeschön!

Können wir das in libelektra-daily oder in einen Cronjob einfügen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Wie Sie vielleicht bemerkt haben, war der Build-Server morgens ausgefallen (jeder vielleicht in der Nacht). Das Netzteil wurde beschädigt und wird nun ersetzt.

Darüber hinaus könnten a7 oder v2 in der nächsten Woche für kurze Laufzeiten für Benchmarks offline gehen. Sie sehen die Offline-Meldung "benchmark", wenn Anton Benchmarks startet. Sollte der Computer zu lange offline bleiben (zB mehr als einen Tag), kontaktieren Sie uns bitte. (Dann wurde möglicherweise vergessen, es wieder online zu schalten.)

Ein Problem mit unserem Sid-Image wurde behoben.

testkdb_allplugins segfaulte in unserem sid-Image während debian-unstable-full-clang-Tests, aber nur bei Ausführung auf v2. Ich habe das Image manuell aktualisiert, um die neuesten verfügbaren Pakete zu verwenden, und es in unsere Registrierung verschoben.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ bestanden, werde es aber im Auge behalten.

Das Problem wurde in #2216 und #2215 ( @mpranj @sanssecours) erwähnt.

Ich habe den öffentlichen Zugriff auf unsere Docker-Registry implementiert. Hier finden Sie eine Dokumentation zum Zugriff darauf.

Lassen Sie mich wissen, wenn etwas nicht wie erwartet funktioniert.

//EDIT Es scheint, als ob das Pushen nicht funktioniert, obwohl die Anmeldung erfolgreich ist.
//EDIT2 öffentlicher Zugriff wird wieder deaktiviert. https://github.com/moby/moby/issues/18569. wiederhergestellte Funktionalität zum Aufbau des Systems
//EDIT3: Public Repo ist wieder online auf hub-public.libelektra.org

Anton will am kommenden Dienstag oder Mittwoch (wir können wählen) das Mainboard des Rechners austauschen, bei dem Hyper-Threading deaktiviert ist. Braucht jemand den Buildserver an einem dieser beiden Tage?

Ich habe die Docker-Registrierung neu gestartet und manuell eine Bereinigung durchgeführt. Hoffentlich wurden dadurch alle Build-Probleme mit dem Website-Image behoben.

@ingwinlu danke für die Wartungsarbeiten!

Leider scheitert die WebUI-Stufe recht zuverlässig, zB 321 oder 320 (schon früher aber auch beim Ziehen von WebUI gescheitert?).

Ich bin immer mehr davon überzeugt, dass die Streichung von Jobs auf Master eine schlechte Idee ist. Wir haben fast keine erfolgreichen Builds auf dem Master, da die Builds entweder abgebrochen werden oder aufgrund von Netzwerkproblemen fehlschlagen. In der Commit-Historie ist es schwer zu sagen, was passiert ist, weil sie so oder so einfach als Fehler angezeigt werden.

Als Workaround habe ich die unzuverlässigen Stufen in c3b59ecef95287ffc33b094b37e03d0ec6b5710f deaktiviert, aber ich hoffe, wir können sie bald wieder aktivieren!

Sollte a7-debian-stretch für die Benchmarks noch offline sein? (seit 21.02.2019 10:47:56 offline genommen)

Vielen Dank für die Meldung! Anscheinend hat Anton vergessen zu reaktivieren. Ich habe den Node wieder aktiviert und auch die alten Nodes entfernt (außer mm, da sie noch laufen).

Am Morgen gab es eine Ausfallzeit unseres Servers. Alles läuft wieder, aber wir haben ein Angebot bekommen, die Hardware auszutauschen. Höchstwahrscheinlich werden wir heute eine weitere Ausfallzeit von etwa einer Stunde haben.

Der Server ist wieder hoch. Leider haben wir die gleiche Hardware. Wenn jemand Zeit für die Installation/Einrichtung hat, können wir die Hardware aufrüsten.

Sieht so aus, als ob die Jenkins-Builds ziemlich langsam sind (mehrere Stunden für einen vollständigen Build). Soweit ich das beurteilen kann, führen nur a7-debian-stretch und i7-debian Tests aus, während alle anderen Knoten im Leerlauf sind. Ist das erwartetes Verhalten?

Vielen Dank für die Meldung dieses Problems!

Nein, das ist kein erwartetes Verhalten. Es scheint, als ob v2 ausgefallen ist. Ich werde es so schnell wie möglich neu starten.

v2 sollte jetzt wieder online sein

v2 ist down und ich fürchte, es wird bis Montag so bleiben. Die Builds werden bis dahin sehr langsam sein.

v2 ist wieder da mit einem neuen Mainboard

Ich werde alle 3 Build-Agenten (i7, v2, a7, in dieser Reihenfolge) auf Buster aktualisieren, um #2852 zu vermeiden

Ich werde versuchen, die Ausfallzeiten so gering wie möglich zu halten. Build-Jobs können fehlschlagen, bitte starten Sie sie neu (nachdem die Agenten wieder hochgefahren sind).

i7-debian-buster, ehemaliges i7-debian-stretch ist wieder online

v2 ist als nächstes

v2-debian-buster und a7-debian-buster sind auch wieder online

Ich habe den vorherigen erfolgreichen Build-Job auf Master neu gestartet, um zu sehen, ob alles wieder funktioniert:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

Darüber hinaus habe ich die PR https://github.com/ElektraInitiative/libelektra/pull/2876 hinzugefügt, um Buster-Build-Jobs zu ermöglichen.

v2 scheint down zu sein (auch ssh-Verbindung schlägt fehl), leider bin ich nicht in Wien. Ich hoffe, unser Systemadministrator wird es morgen beheben.

a7 ist jetzt auch unten und damit i7 (das über Brücke über a7 verbunden ist).

Daher können derzeit keine Builds durchgeführt werden. Ich habe den Administrator kontaktiert.

Alle Server sind wieder hoch. Bitte starten Sie die Builds neu, indem Sie entweder neue Commits pushen oder "jenkins build libelektra please" als Kommentar zu Ihrem PR schreiben.

Technische Anmerkung: a7 ist wegen "Watchdog Bug Soft Lockup" heruntergekommen. Ich habe versucht, "nomodeset nmi_watchdog=0" hinzuzufügen. Hoffen wir, dass sie nicht wieder so instabil sind, wie sie es schon waren.

a7 (und auch v2 und i7, weil sie über eine Brücke über a7 verbunden sind) sind unten. Ich habe unseren Administrator kontaktiert. Bitte vermeiden Sie es jetzt, Builds zu starten, da dies nur eine lange Warteschlange bildet.

a7 ist wieder online (war schon gestern), v2 war nicht betroffen

Laut der Build-Server-Statusseite sind die Server:

• a7-debian-buster ,
• i7-debian-buster , und
• v2-debian-buster

sind unten. Das Datenverzeichnis von Jenkins scheint auch ziemlich voll zu sein. Und wenn wir schon dabei sind: Es wäre toll, wenn wir Jenkins und seine Plugins aktualisieren könnten. Ich bin daran interessiert, diese Probleme zu beheben. Es gibt jedoch zwei Probleme.

1. Ich habe nicht viel (oder wirklich keine) Erfahrung mit der Verwaltung von Servern.
2. Ich würde wahrscheinlich physischen Zugriff auf die Maschinen benötigen, da sie ziemlich instabil zu sein scheinen.

a7 ist eine Brücke zu i7 und v2, also wissen wir nichts über i7 und v2, da a7 unten ist.

Der Zugang ist kein Problem, ich kann ihn dir geben. Aber Sie sollten sich bewusst sein, dass das Upgrade von Jenkins eine große Operation ist, da es normalerweise erfordert, Jenkins neu zu konfigurieren (gemäß den Versionshinweisen, die wir seit einiger Zeit nicht mehr aktualisiert haben) und die Jenkins-Datei zu reparieren (gemäß API-Änderungen von den Plugins) ). Schreiben Sie mir eine E-Mail, wenn Sie Zugang wünschen.

a7 (und alle anderen) sind wieder oben.

a7 ist wieder down, ich habe den Admin kontaktiert.

Technische Anmerkung: a7 ist wegen "Watchdog Bug Soft Lockup" heruntergekommen.

Eine schnelle Suche deutet darauf hin, dass dies ein BIOS-Problem sein könnte. Hat jemand nachgesehen, ob BIOS-Updates verfügbar sind?

a7 ist eine Brücke zu i7 und v2, also wissen wir nichts über i7 und v2, da a7 unten ist.

Das scheint ein schlechtes Design zu sein. Gibt es keinen Weg daran vorbei?

Eine schnelle Suche deutet darauf hin, dass dies ein BIOS-Problem sein könnte. Hat jemand nachgesehen, ob BIOS-Updates verfügbar sind?

Wir haben ein neues BIOS installiert, die CPU getauscht und den Kernel aktualisiert (siehe Meldungen oben). Das System war seitdem stabil. Jetzt nach dem Upgrade auf Debian Buster ist es wieder instabil.

Trotzdem habe ich den Admin gefragt, ob es ein neues BIOS gibt.

Das scheint ein schlechtes Design zu sein. Gibt es keinen Weg daran vorbei?

i7 und v2 befinden sich in einem privaten Netzwerk, da nicht genügend IPv4-Adressen vorhanden sind. Ich habe unseren Admin gefragt, ob vielleicht ein IPv6-Setup möglich wäre.

Ich habe unseren Admin gefragt, ob vielleicht ein IPv6-Setup möglich wäre.

Wir brauchen IPv6 nicht wirklich, es würde ausreichen, einen anderen, stabileren Server als Bridge zu verwenden.

Höchstwahrscheinlich ist v2 so instabil wie a7 (es gab nur einen Absturz, aber das sagt nicht viel aus, denn sofort, wenn a7 stirbt, nimmt es die Last von v2 auf. Wir könnten i7 als Bridge verwenden. Aber wenn v2 und a7 ausfallen, ist i7 auch nicht von großem Nutzen, es würde viele Stunden dauern, einen Build-Job zu beenden. Außerdem hat i7 nicht genug Platz für die Docker-Registry.

Diese Änderung wäre also ein großer Aufwand mit wenig Gewinn.

Viel vielversprechender ist es, das eigentliche Problem von a7 und v2 zu beheben.

Außerdem hat i7 nicht genug Platz für die Docker-Registry.

In diesem Fall besteht die einzige Lösung darin, a7 zu reparieren.

Leider ist a7 wieder unten :cry:

Ich habe versucht, mit dem alten Kernel zu booten, aber das hat nicht geholfen.

Für das BIOS gibt es noch einige andere Versionen, aber laut den Release Notes besteht wenig Hoffnung, dass sie dieses Problem beheben und es gibt keine Möglichkeit, erneut downzugraden, wenn es schlimmer werden würde...

Das BIOS für a7 wird derzeit aktualisiert. Außerdem werden wir versuchen, einen neueren Kernel von Backports zu verwenden.

a7 wird hoffentlich bald wieder aufstehen.

Das neue BIOS half nicht, jetzt stürzte a7 innerhalb von Minuten ab.

a7 ist wieder down, ich habe den Admin kontaktiert. Der neuere Kernel von Backports wird beim nächsten Neustart ausprobiert.

a7 ist mit dem 5.2-Kernel wieder oben

Ich glaube, es ist wieder abgestürzt...

Bekommen wir immer noch die gleichen Fehlermeldungen oder ändert sich zumindest etwas?

Ja, a7 wieder runter, habe ich dem Admin gemeldet. Er wird uns beim Neustart über die Nachrichten informieren.

Hat jemand eine andere Idee? (Wir haben bereits BIOS und Kernel aktualisiert.)

Einige Quellen schlagen Probleme mit dem neuen Grafiktreiber vor und wir sollten es mit nouveau.modeset=0 versuchen (irgendwie unterscheidet sich dies von nomodeset ). Auch das Deaktivieren von "C-States" im BIOS wurde vorgeschlagen.

Ja, a7 wieder runter, habe ich dem Admin gemeldet. Er wird uns beim Neustart über die Nachrichten informieren.

Hat jemand eine andere Idee? (Wir haben bereits BIOS und Kernel aktualisiert.)

Vielleicht deaktivieren Sie a7 als Jenkins-Slave, um festzustellen, ob dies nur auftritt, wenn die Maschine "echt" geladen ist.

@ingwinlu danke, gute Idee. Ich habe jetzt auf einen Baujob a7 reduziert (es war 2). Für das Wochenende (nachdem der Admin das Büro verlassen hat) werde ich den Agenten dann komplett deaktivieren.

@kodebach : danke, ich werde die Informationen an den Admin weiterleiten.

Gibt es eine Zeitleiste, wann a7 wieder hoch ist?

a7 ist wieder aktiv, mit deaktiviertem Hyperthreading und nur einem gleichzeitigen Build-Job.

Wir könnten a7 auch etwas entlasten, indem wir die Builds alpine und ubuntu-xenial nach Cirrus verschieben. Beides sind einfache "Build-and-Test"-Läufe. Sie machen nichts Besonderes wie Berichterstattung.

Cirrus erlaubt 8 gleichzeitige Linux-Builds pro Benutzer . Derzeit ist der linkchecker Build der einzige Linux-Build auf Cirrus.

Tatsächlich ist ubuntu-xenial etwas überflüssig, da unsere Travis-Builds auf Ubuntu Xenial laufen.

Vielen Dank für die Tipps, aber wir planen nicht, Linux-Builds von Jenkins wegzuladen. Im Gegenteil, @Mistreatment wird daran arbeiten, unsere Jenkins-Infrastruktur noch aktueller und nützlicher zu machen (zB durch das

1. wir haben es voll im Griff
2. wir können es leicht skalieren (nur Java + Docker ist für Build-Agenten erforderlich)
3. das Jenkinsfile ist sehr ordentlich und (größtenteils) recht einfach erweiterbar

Aber natürlich ist auch jeder willkommen, Cirrus (oder jedes andere kostenlos angebotene zusätzliche Build-System, siehe #1540) zu erweitern.

Es war nur als vorübergehende Lösung gedacht, um der Deaktivierung von Hyperthreading und der Beschränkung auf 1 gleichzeitigen Job auf a7 entgegenzuwirken.

a7 baut nur einen kleinen Teil (ca. 2/5), daher sollte die Reduzierung um die Hälfte kaum wahrnehmbar sein. Oder gibt es jetzt spezielle Probleme? (Im Moment braucht es natürlich Zeit, um die vielen Jobs aus der Ausfallzeit nachzuholen.)

a7 bildet nur einen kleinen Teil (ca. 2/5)

2/5 ist 40%. Das würde ich nicht als kleinen Teil bezeichnen.

Oder gibt es jetzt spezielle Probleme?

Nein, tatsächlich scheint es besser zu funktionieren als zuvor.

Entschuldigung, ich meinte ungefähr 2/6 (1/6 ist i7, 3/6 ist v2). Und dieser Teil wird nicht entfernt, sondern nur reduziert.

Nein, tatsächlich scheint es besser zu funktionieren als zuvor.

Perfekt!

Scheint so, als ob a7 wieder unten ist 😭.

Dankeschön! Ich habe es gemeldet.

In Zukunft wäre es toll, wenn derjenige, der zuerst entdeckt, es direkt melden kann

herbert at complang.tuwien.ac.at

Es genügt zu sagen, dass "a7 leider nicht erreichbar" ist.

Und dann auch hier melden, damit Herbert nicht mehrere Emails bekommt.

Sicherlich gibt es eine Möglichkeit, den Jenkins-Masterserver dazu zu bringen, eine solche E-Mail automatisch zu senden und vielleicht auch in diesem GitHub-Problem zu posten. Es wäre sehr seltsam, wenn es für so eine einfache Aufgabe kein Jenkins-Plugin gäbe...

Ja, es gibt https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin, aber ich bin mir nicht sicher, ob es genau das tut, was wir wollen. Es kann auch E-Mails senden, wenn jemand den Agenten absichtlich vertröstet. Und eine persönliche E-Mail wird vom Administrator viel schneller bearbeitet.

Wenn wir etwas automatisieren, dann direkt den Neustart der PCs, wenn sie nicht erreichbar sind (vielleicht haben sie sogar eine Art Watchdog eingebaut?)

a7 wurde neu gestartet und die "globale C-State-Steuerung" deaktiviert.

Es ist jedoch nicht als Build-Agent online.

Mal sehen, ob es auch ohne Last abstürzt. v2 und i7 funktionieren wieder.

Der Admin (Herbert) ist morgen nicht erreichbar, daher lasse ich a7 vorerst als Build-Agent frei.

Mein Plan (wenn es vorher keine Proteste gibt oder a7 abstürzt) ist, morgen a7 als Build-Agent einzuschalten. Wenn a7 dann wieder abstürzt, kann Herbert a7 am Freitag neu starten. Ist das okay?

Wenn die Warteschlange nicht zu lang ist, sollten wir den Build-Agenten auf a7 meiner Meinung nach noch etwas länger deaktivieren. Der letzte Absturz passierte nach 3 Tagen. Wenn wir es morgen aktiviert haben, wissen wir nicht, ob der Build-Agent den Absturz verursacht hat oder nicht, es sei denn, er stürzt vorher ab.

Ok, dann sehen wir uns an, wie die Warteschlangengröße aussieht.

Ich hoffe, dass die "globale C-State-Kontrolle" das Problem endlich behebt und ich denke, wir brauchen eine hohe Last, um es zu testen.

Die Warteschlange war sehr lang und die Master-Builds hingen alle, da sie a7 für die Website-Bereitstellung benötigen.

Also habe ich den a7-Agenten wieder gestartet.

Einige der letzten Jenkins-Build-Jobs wurden abgebrochen, weil auf dem Haupt-Build-Server Speicherplatz fehlt. Ich habe etwas Speicherplatz frei gemacht, indem ich Protokolle alter Build-Jobs entfernt habe. Bitte beachten Sie, dass ich möglicherweise auch einige Protokolldateien von neuen Build-Jobs entfernt habe. In einigen Fällen ist der Jenkins-Build für Ihren letzten Commit möglicherweise fehlgeschlagen und Sie sehen jetzt nur eine Meldung über einen 404-Fehler. In diesem Fall bitte einfach entweder

• Verwenden Sie jenkins build libelektra please in einem Kommentar unter dem PR, um den Jenkins-Build neu zu starten, oder
• den letzten Commit ohne Änderungen neu schreiben (zB mit git commit --amend ) und einen Force-Push durchführen

. Entschuldigen Sie die Unannehmlichkeiten.

Vielen Dank für die Pflege!

Ich habe den Knoten v2-debian-buster als vorübergehend offline markiert, da er nicht richtig zu funktionieren scheint. Weitere Informationen finden Sie in Ausgabe #2995 (und Ausgabe #2994).

Vielen Dank für die Suche nach der Infrastruktur!

v2 hatte keinen Speicherplatz mehr. Ich habe docker system prune Insgesamt zurückgeforderter Speicherplatz: 58,37 GB

Dann habe ich v2 neu gestartet und den Agenten erneut verbunden.

Ich habe jetzt du -h | sort -h , um andere zu entfernende Dateien zu finden.

Ich habe v2 wieder mit einer neuen Docker-Version gestartet. Bitte melden Sie defekte Builds sofort.

Ich habe Docker neu installiert, alle Konfigurationen gelöscht und /var/lib/docker entfernt. Hoffentlich wird es dadurch behoben.

v2 wird wieder aufgenommen. Bitte melden Sie defekte Builds sofort.

Wie hier vorgeschlagen

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

und ich habe auch i7 neu gestartet (es gab viele Docker-Netzwerkschnittstellen, sie sind jetzt weg)

docker-ce ist jetzt überall 5:19.03.1~3-0~debian-buster

Bitte melden Sie defekte Builds sofort.

Sieht so aus, als ob der master Build erneut fehlgeschlagen ist , wegen Verbindungsproblemen zu v2-debian-buster (siehe auch Ausgabe #2995).

Ich habe unseren Admin gebeten, sich den Wechsel zwischen a7/v2/i7 anzusehen. Ich habe v2 und i7 vorerst deaktiviert.

Ich habe libelektra/master und libelektra-daily neu gestartet.

Wir haben die Ports für alle 3 PCs geändert.

Dann habe ich Jenkins Homedir auf v2/i7 entfernt und den v2/i7-Agenten neu gestartet.

Anscheinend ist auf v2-debian-buster kein Speicherplatz mehr verfügbar :

ApplyLayer Exit-Status 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: kein Platz mehr auf dem Gerät

.

Vielen Dank für die Meldung, ich habe (viel) mehr Platz auf v2.

Auftrag entfernen abgeschlossen:

Verwendete Dateisystemgröße Avail Use% Mounted on
/dev/sda3 417G 227G 164G 58 % /

buildserver ist wegen Migration ausgefallen (damit wir einen konsistenten Zustand im Backup des neuen buildservers erhalten)

https://build.libelektra.org/jenkins/ geht wieder

Load on build server war 200 aufgrund von Kernelfehlern während eines Backups, der Server reagierte nicht mehr und musste zurückgesetzt werden.

Protokollmeldungen waren (Beispiele):

[87400.120008]  [<ffffffff810be6a8>] ? find_get_page+0x1a/0x5f

[87372.120005]  [<ffffffff81357f52>] ? system_call_fastpath+0x16/0x1b
[87372.120005] Code: f6 87 d1 04 00 00 01 0f 95 c0 c3 50 e8 d7 36 29 00 65 48 8b 3c 25 c0 b4 00 00 e8 d0 ff ff ff 83 f8 01 19 c0 f7 d0 83 e0 fc 5a c3 <48> 8d 4f 1c 8b 57 1c eb 02 89 c2 85 d2 74 16 8d 72 01 89 d0 f0
[87372.120005] Call Trace:
[87372.120005]  [<ffffffff810be6cc>] ? find_get_page+0x3e/0x5f
[87372.120005]  [<ffffffffa016962f>] ? lock_metapage+0xc2/0xc2 [jfs]

[87400.110012] BUG: soft lockup - CPU#0 stuck for 22s! [cp:15356]

Hoffentlich können wir Anfang nächster Woche bald migrieren ( @Mistreatment ?)

Der Server führt derzeit eine Neusynchronisierung des Raids durch, also erwarten Sie, dass es sehr langsam ist.

Jenkins-Builds werden nicht mehr ausgeführt, siehe #3035

Jenkins fing jetzt wieder an. Bitte wiederholen Sie Jenkins-Build-Jobs.

Anscheinend ist v2-debian-buster offline:

Öffnen der SSH-Verbindung zu a7.complang.tuwien.ac.at:22221.
Verbindung abgelehnt (Verbindung abgelehnt)

.

Vielen Dank, ich habe unseren Administrator kontaktiert, aber ich fürchte, er wird bereits abwesend sein.

Herbert hat v2 bereits gestern neu gestartet. Er hat "simultanes Multithreading" deaktiviert.

Sollte ein Server (v2, i7, a7) erneut abstürzen, wenden Sie sich bitte ebenfalls direkt an unseren Admin über "herbert at complang.tuwien.ac.at". Bitte melden Sie sich auch hier, um Mehrfach-E-Mails zu vermeiden.

Ich denke , mit dem Git-Repository für den master Zweig auf v2-debian-buster stimmt etwas nicht :

git fetch --tags --progress https://github.com/ElektraInitiative/libelektra.git +refs/heads/master:refs/remotes/origin/master +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
fatal: loose object 9c0bc3ca6fcbc610abd845aeff5f666938d24117 (stored in .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117) is corrupt
fatal: the remote end hung up unexpectedly

. Ich habe den Build bereits dreimal neu gestartet, aber Jenkins schlägt immer mit dem gleichen Fehler fehl.

Leider hat v2 btrfs, die manchmal Dateien zu beschädigen scheinen. Ein ähnliches Problem hatten wir bereits mit einem fehlgeschlagenen docker pull . Im aktuellen Fall scheint die Datei 0bc3ca6fcbc610abd845aeff5f666938d24117 beschädigt zu sein. Wenn ich md5sum für die Vorkommen dieser Datei ausführe, erhalte ich:

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

Ich habe jetzt das gesamte Verzeichnis für master entfernt und den Build neu gestartet. Siehe auch #3054

Da ich nun seit einigen Tagen nicht erreichbar bin, wenden Sie sich bitte an "herbert at complang.tuwien.ac.at" bei Problemen bezüglich nicht erreichbarer a7/i7/v2. @Mistreatment ist für alles verantwortlich, was nicht mit dem Neustart von Servern zu tun hat. (Hoffentlich bekommen wir bald einen neuen Bauagenten.)

Bitte melden Sie sich auch immer hier, um Mehrfach-E-Mails zu vermeiden und damit jeder einen guten Überblick über das Geschehen hat.

Hat der Buildserver aktuell eine Störung?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

Hat der Buildserver aktuell eine Störung?

Es scheint, als ob der Haupt-Build-Server von Jenkins keine Verbindung zu i7 . Ich habe den Knoten als vorübergehend offline markiert.

Der Build schlägt in willkürlichen Fällen fehl:
Hier wurde es ohne Grund unterbrochen
Hier schlägt ein Testfall fehl, der nichts mit meiner PR zu tun hat (ich habe gerade eine Designentscheidung hinzugefügt, ohne Code zu berühren)

Hier wurde es ohne Grund unterbrochen

Ich habe den gleichen Unterbrechungscode 143 für zwei PRs erhalten und kann sie noch nicht erklären. Ich habe den Build neu gestartet und hoffe, dass es jetzt funktioniert.

Hier schlägt ein Testfall fehl, der nichts mit meiner PR zu tun hat

Dies sollte dank @sanssecours mit #3103

Der neue Jenkins-Knoten hetzner-jenkins1 scheint nicht richtig zu funktionieren . Ich habe den Knoten als vorübergehend offline markiert.

Ich habe Docker auf i7 aktualisiert und den Computer neu gestartet. Ich hoffe, das behebt das Problem. Der Agent ist wieder online. Bitte melden Sie hier Probleme (und/oder deaktivieren Sie den Agenten).

Derzeit läuft ein Job von #3065 auf i7.

@Misshandelt können Sie bitte hetzner-jenkins1 debuggen?

Gibt es eine Möglichkeit einen Linkcheck für einige Zeit einfach abzuschalten?

Das passiert den ganzen Tag:

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

Andere PRs (zuletzt #3115, #3113) sind ebenfalls betroffen. Laut downforeveryoneorjustme sind Links wirklich nicht verfügbar.

UPDATE: Die Website ist noch offline. Ich habe eine PR für diese #3117 gemacht.

Gibt es eine Möglichkeit einen Linkcheck für einige Zeit einfach abzuschalten?

Sie können einzelne Links deaktivieren, indem Sie sie zur tests/linkchecker.whitelist hinzufügen (wie Sie bereits herausgefunden haben)

Ich kann fehlgeschlagene Builds von Cirrus nicht wiederholen. Siehe https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

Der Knopf macht nichts. Gibt es einen Zaubertrick, damit es funktioniert?

edit: entweder hat jemand etwas geändert oder der x-te versuch hat endlich geklappt. Der Build läuft wieder! :)

Anscheinend kann der Build-Agent a7-debian-buster nicht neu gestartet werden:

…
[10/28/19 06:02:59] [SSH] Starting slave process: cd "/home/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout

.

edit: entweder hat jemand etwas geändert oder der x-te versuch hat endlich geklappt. Der Build läuft wieder! :)

Nachdem ich Ihren Kommentar gesehen habe, habe ich auch den Button „Failed Build Jobs neu starten“ gedrückt. Soweit ich das beurteilen kann, hat das Drücken der Taste die fehlgeschlagenen Build-Jobs tatsächlich neu gestartet.

Nachdem ich Ihren Kommentar gesehen habe, habe ich auch den Button „Failed Build Jobs neu starten“ gedrückt. Soweit ich das beurteilen kann, hat das Drücken der Taste die fehlgeschlagenen Build-Jobs tatsächlich neu gestartet.

Bei mir hat es jedoch nicht funktioniert, ich werde das nächste Mal ein Gif bereitstellen!

Ich werde den Build-Server und seine Knoten neu starten. Build-Jobs von #3121 und #3099 müssen neu gestartet werden, da sie Jobs für tote Agenten hatten.

Bei mir hat es jedoch nicht funktioniert, ich werde das nächste Mal ein Gif bereitstellen!

Du brauchst kein GIF zur Verfügung zu stellen, da ich dir schon glaube 😊.

Scheint, als hätte Jenkins Probleme, zu stoppen, ich warte ein bisschen, bevor ich alle Java-Prozesse gewaltsam beende.

Ich habe auch Docker auf allen Agenten aktualisiert (auf i7 wurde es bereits aktualisiert).

Jenkins ist mit dem in #2984 vorgeschlagenen Heartbeat-Intervall wieder oben. Alle Knoten sind verbunden.

Bitte starten Sie alle Jobs nach Bedarf neu und melden Sie alle Probleme hier.

v2 ist ausgefallen, ich habe unseren Administrator gebeten, neu zu starten.

Ich habe v2 wieder aktiviert, da es zu laufen scheint und unser Build-Backlog ausreichend groß ist.

Gibt es wieder ein Problem mit dem Build ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

Gibt es wieder ein Problem mit dem Build ( hetzner-jenkins1 )?

Ja . Ich habe den Knoten deaktiviert.

Es hat nur das Festplattenkontingent überschritten, ich wollte es nicht mit Speicher überfrachten. Ich habe es jetzt aufgeräumt. Es ist wieder soweit.

Knoten aktualisiert.

Ich habe hetzner-jenkins1 auf 4 parallele Builds erhöht. Dies ist nur eine vorübergehende Maßnahme, solange dort nichts anderes läuft.

Ich habe die Anzahl der Executors auf hetzner-jenkins1 vorübergehend von 4 auf 2 reduziert, da die Testsuite ein Timeout hat. Ich denke, das passiert, wenn zu viele Jobs kompiliert werden, während Tests ausgeführt werden. Möglicherweise müssen wir die verfügbaren Ressourcen auf einen einzelnen Container beschränken, damit andere Aufgaben nicht zu sehr beeinträchtigt werden.

Fühlen Sie sich frei, es zu korrigieren, wenn Sie denken, dass dies der falsche Ansatz war.

BEARBEITEN: auf 1 verringert, da die Tests immer noch ablaufen und der ständige Wiederaufbau noch mehr Ressourcen verschwendet.

@mpranj Vielen Dank für die

@misshandelt hast du vielleicht nur eine einzelne CPU oder ähnliches zugewiesen? Können Sie mehr zuweisen und die Anzahl der Ausführenden erhöhen? Die Hardware sollte stärker sein als v2.

Ich habe i7-debian-buster deaktiviert, weil kein Speicherplatz mehr vorhanden ist, was dazu führt, dass alle Builds fehlschlagen. Wenn jemand Zugriff hat, bereinigen Sie bitte etwas und aktivieren Sie es erneut.

@mpranj danke für die Deaktivierung!

Sorry, wo ich mich gerade befinde ist ssh blockiert (einige Anwendungsfirewall, auch ssh auf anderen Ports funktioniert nicht). Daher kann ich jetzt keinen Zugriff gewähren oder keine Bereinigung durchführen.

Da i7 der schwächste der Agenten ist, könnte es sowieso keine große Sache sein.

@Misshandelt hast du vielleicht nur eine einzelne CPU oder ähnliches zugewiesen? Können Sie mehr zuweisen und die Anzahl der Ausführenden erhöhen? Die Hardware sollte stärker sein als v2.

Ich habe keine Ahnung, wie stark v2 ist.
Derzeit verwendet jenkins1 4 CPUs mit 8 Speicher und 16 Swap. Ich kann es leicht erhöhen, ich weiß nur nicht, bis zu welchem ​​​​Punkt Sie möchten, dass ich es erhöhe.

Ein Hinweis für die zukünftigen Hardware-Entscheidungen: Phoronix scheint in seinen CPU-Artikeln Kompilationstests durchzuführen (zB Ryzen 7 3700X, Ryzen 9 3900X Test, am unteren Ende des Artikels ).

Anscheinend hat Hetzner kürzlich AMD Ryzen 7 3700X zu seinen AMD-basierten Servern hinzugefügt.

Ich habe keine Ahnung, wie stark v2 ist.

@ingwinlu hat darüber in seiner Diplomarbeit geschrieben (zu finden in abgaben repo lukas_winkler)

Derzeit verwendet jenkins1 4 CPU mit 8 Speicher und 16 Swap. Ich kann es leicht erhöhen, ich weiß nur nicht, bis zu welchem ​​​​Punkt Sie möchten, dass ich es erhöhe.

Solange auf dem Server nichts anderes läuft, können Sie alle Ressourcen zuweisen. Später können wir noch absteigen (wenn wir Jenkins bewegen).

Ich habe die hetzner-jenkins1 aktualisiert.
Der Fehler mit dem Frontend, bei dem der Speicher knapp wird, wurde behoben.
Jetzt laufen 2 parallele Builds.

Anscheinend ist kein Platz mehr auf v2-debian-buster :

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

Danke, ich habe es auch offline markiert, bis jemand Zugriff hat, um es zu bereinigen.

hetzner-jenkins1 gerade meine 3 PRs fehlgeschlagen, weil das Festplattenkontingent überschritten wurde. Hier ist auf der Ausgabe:

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on hetzner-jenkins1
/home/jenkins/workspace/libelektra_PR-3106-LB35J55FSRLFKFEU2WP6AWVLM3IH4JWI6C5B57NWB6DDARN4JDUA@tmp/ff803792-a127-4b8f-8588-439af982c8a4: Disk quota exceeded

hetzner-jenkins1 als offline markiert, weil das Festplattenkontingent überschritten wurde.

Ich habe i7 und v2 aufgeräumt (indem ich /home/jenkins/workspace/* entfernt und docker system prune ). Jetzt haben wir:

• i7: /dev/mapper/i7--vg-home 199G 152G 37G 81% /home
• v2: /dev/sda3 417G 255G 147G 64 % /

Dann habe ich die Agenten neu gestartet.

@Misshandelt können Sie bitte #3160 reparieren, damit dies nicht so schnell wieder

Ich weiß nicht, ob es eine nette Möglichkeit gibt, die Größe der Festplatte zu verkleinern. Deshalb gebe ich dem Knoten nicht alles auf einmal.. hetzner ist wieder da.

v2 hatte wieder keinen Platz mehr, ich habe aufgeräumt: /dev/sda3 417G 315G 102G 76% /

@Mistreatment https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log startet nicht

Ich denke, das Build-System hängt derzeit komplett fest, PRs werden nicht gebaut.

Vielen Dank für Ihre Meldung. Ich werde Jenkins neu starten und einige Dateien bereinigen, wenn die Disc voll ist.

@Mistreatment https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log startet nicht

Agent erfolgreich verbunden und online

Ich gehe davon aus, dass mit hetnzer-jenkins1 jetzt alles in Ordnung ist?

Ich danke dir sehr! Anscheinend reagiert Jenkins immer noch nicht auf Builds. v2 und i7 schlagen jetzt beide fehl mit: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins ist wieder aktiv, bitte starten Sie die Jobs neu.

java.io.IOException: slave.jar konnte nicht nach '/home/jenkins' auf dem Slave kopiert werden.

behoben (war auch kein Platz mehr)

@Missulated bitte repariere die Jenkins-täglich, da dies die Bereinigungsaufgaben macht, die wir jetzt immer manuell erledigen müssen!

@Missulated "

Versuchen Sie vielleicht noch heute, auf die neuen Jenkins zu wechseln, aber wenn Sie dies nicht können, bringen Sie die alte Instanz bitte wieder zum Laufen!

Ich habe einen Repository-Scan ausgelöst, jetzt scheint das "jenkins build libelektra please" wieder zu funktionieren.

Anscheinend ist die Festplatte für v2-debian-buster voll

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

Bedauerlicherweise. Ich habe v2 als offline markiert, bis das Problem behoben ist.

Vielen Dank für die Meldung!

@mpranj Ich habe dir Zugriff gegeben, kannst du bitte versuchen zu bereinigen?

Dankeschön! Es scheint mir, dass eine Fülle von Ressourcen verschwendet wird, indem alte Docker-Images herumliegen. Außerdem scheint es, dass btrfs + docker fehlerhaft sind. Docker erstellt btrfs-Subvolumes für jeden Container und bereinigt ihn danach nicht richtig. Auch der Befehl docker system prune -f gibt den Speicherplatz nicht frei.

Ich habe v2 und a7 wegen Wartungsarbeiten heruntergefahren, um die Ressourcen freizugeben und die Btrfs auszugleichen.

Docker-Anmeldung fehlgeschlagen

Build kann Docker-Images nicht abrufen. Ist etwas mit Docker Hub los?

Ja, tut mir leid, mit a7 ich auch den Docker-Hub abgebaut. Ich werde hier eine Nachricht posten, wenn es wieder soweit ist.

a7 inklusive Docker Hub ist wieder aktiv. Ich habe v2 offline gelassen, weil es sich nicht beim Hub anmelden kann, um Bilder abzurufen?!? Ich weiß nicht, was da falsch ist, ich habe keine Anmeldeinformationen oder so geändert und die anderen Knoten können sich anmelden. Irgendwelche Ideen?

Btrfs balanciert immer noch im Hintergrund, a7 kann für eine weitere Stunde oder so langsamer sein.

@mpranj danke, dass du das

Leider kenne ich die Zugangsdaten nicht, ich hoffe @ingwinlu kann uns weiterhelfen.

Die Befehle, die ich zum Neuausgleich verwendet habe, waren:

Behebung eines Vielleicht-Bugs mit btrfs:

btrfs balance start -dusage=0 -musage=0 /mountpoint

Richten Sie die fs wirklich neu aus, das dauert lange. Der Nutzungsparameter kann/sollte angepasst werden, so hat es heute funktioniert:

btrfs balance start -dusage=80 /

Die Zugangsdaten können leicht geändert werden, aber wir müssten alle Jenkins-Agenten, die sich mit dem Docker-Hub verbinden, mit den neuen Zugangsdaten erneut anmelden.

Das größere Problem war, dass einige Docker-Container noch liefen und das Bereinigen des Docker-Systems nicht viel bewirkte. Deshalb habe ich die Agenten abgebaut und alles freigegeben, während es unten war. Es lagen TONNEN Container herum.

Ja, leider werden die Container schnell neu erstellt. Ich hoffe, @Mistreatment kann den libelektra-daily-Job bald reparieren (er führt docker system prune ).

Ich habe auch einige ziemlich aufwendige digitale Forensiken durchgeführt und die Zugangsdaten des Hubs gestohlen. :Lachen:

v2 läuft wieder.

Ich danke dir sehr! :100: Bitte senden Sie uns die Zugangsdaten.

Gesendet. Übrigens denke ich, dass a7 wahrscheinlich nur wegen der schlechten Festplattengeschwindigkeit langsam ist, aber es ist gut, dass es genug Platz für den Docker-Hub hat. Scheint, als würde die CPU dort die meiste Zeit nichts tun.

Ein weiterer Gedanke: Vielleicht können wir die kritischen Aufräumarbeiten zusätzlich per Cronjob erledigen, um Situationen wie jetzt zu vermeiden.

Bitte senden Sie uns die Zugangsdaten.

@mpranj Ich glaube, ich war in dieser Gruppe von "uns". Ich war nicht in einem CC oder so?

@Missulated Entschuldigung, ich habe es an markus gesendet und hatte deine E-Mail nicht. Auf a7 findest du CREDENTIALS.txt in deinem Homedir.

Ich benötige hetzner-jenkins1 Node um den neuen jenkins-server zu testen. Ich werde es bis morgen früh auf dem alten Server ausschalten.

Für Tests können Sie ganz einfach einen zweiten hetzner-jenkins2 erstellen. Wenn es nur für diese Nacht ist, sollte es jedoch in Ordnung sein.

Ein weiterer Gedanke: Vielleicht können wir die kritischen Aufräumarbeiten zusätzlich per Cronjob erledigen, um Situationen wie jetzt zu vermeiden.

libelektra-daily erledigt diese Aufräumarbeiten, aber es schlägt jetzt fehl: #3160. Wenn Sie Ideen haben, um diesen Job zu verbessern, teilen Sie uns dies bitte mit.

Ich glaube, ich war in dieser Gruppe von "uns". Ich war nicht in einem CC oder so?

Ja, es tut mir leid, dass ich vergessen habe, mpranj zu sagen, dass sich "uns" auf Sie bezieht.

Ich hoffe, dass es in Ordnung ist, dass ich hetzner-jenkins1 eine Weile behalte, alle Builds sind jetzt gut. Ich denke, ich kann den Server heute Abend vollständig zum Laufen bringen.

v2 ist nicht erreichbar, ich habe den Admin kontaktiert.

Ich hoffe, dass es in Ordnung ist, dass ich hetzner-jenkins1 eine Weile behalte, alle Builds sind jetzt gut. Ich denke, ich kann den Server heute Abend vollständig zum Laufen bringen.

Das wäre toll!

v2 ist nicht erreichbar, ich habe den Admin kontaktiert.

Danke, aber ich fürchte, er wird nicht vor Montag antworten.

v2 bekommt einen neuen Kernel (er ist gerade abgestürzt).

i7 wird auch neu gestartet.

Alle 3 Server (v2, a7, i7) haben jetzt "Linux v2 5.2.0-0.bpo.2-amd64 #1 SMP Debian 5.2.9-2~bpo10+1 (2019-08-25) x86_64 GNU/Linux ." "

Sie sind aktiv und online, bitte starten Sie die Jobs bei Bedarf neu.

Nur eine Notiz:
Ich habe das Repo erneut mit dem neuen Server gescannt. Dies könnte einige Fehler auf dem alten machen..

Scheint, als ob master [1] auch auf dem neuen Server gebaut wurde. Es war nicht erfolgreich. Beim Klick auf den Status erscheint eine Login-Seite [2]. Bitte rekonfiguriere Jenkins so, dass alles angezeigt werden kann, ohne eingeloggt zu sein.

Hoffentlich können wir bald auf die neuen Jenkins umsteigen. Fehler von zwei verschiedenen Jenkins zu sehen macht die Situation nicht einfacher :wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@markus2330 kann a7 / v2 nach einem Upgrade aus der Ferne neu gestartet werden oder gibt es einige Fallstricke?

Normalerweise funktioniert es, aber wenn es nicht dringend ist, ist es besser zu warten, bis der Admin da ist. Ich kann am Dienstag neu starten, wenn das für Sie in Ordnung ist?

Dankeschön! Nichts dringendes, nur eine allgemeine Frage. Es kam auf, weil Debian 10.2 gerade veröffentlicht wurde. Mit den Upgrades warte ich noch ein bisschen.

Sie können das Upgrade trotzdem durchführen (nur ohne Neustart). Dann haben wir im Falle eines Absturzes bereits den 10.2-Kernel, wenn der Admin den Reset-Knopf drückt :wink:

@mpranj können Sie vielleicht einen Cronjob hinzufügen, der die alten Snapshots löscht? Oder ist dies nicht möglich, ohne Docker zu stoppen?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ empfiehlt, auch btrnfs in einem Cronjob neu auszugleichen.

Kannst du vielleicht einen Cronjob hinzufügen, der die alten Snapshots löscht? Oder ist dies nicht möglich, ohne Docker zu stoppen?

Ich kann einen Cronjob hinzufügen, ohne alle Docker-Container zu stoppen. Das wird vielleicht nicht alles bereinigen, aber wir können es versuchen. Wie gesagt, Container laufen manchmal ewig/bis die Maschine abstürzt. Die vollständige Bereinigung erfordert jedoch, dass wir den Build-Agent vorübergehend deaktivieren, dann können wir das Stoppen aller Container erzwingen.

Ich kann das Rebalancing auch als Cronjob hinzufügen.

Danke, lass es uns versuchen.

Der Meister hat keinen Speicher mehr. Ich wollte Scan Repository auf dem alten Jenkins ausführen, da a7 und i7 beim Ziehen von Docker-Images folgenden Fehler erhalten:

Docker-Anmeldung fehlgeschlagen

Ich habe jetzt v2 und hetzner-jenkins1 auf dem neuen Server laufen.

Der Meister hat keinen Speicher mehr.

Danke für die Berichterstattung. Ich habe einige alte Abdeckungsdaten entfernt und den Masterknoten wieder aktiviert. Für alle mit offenen Pull-Requests: Bitte starten Sie Ihre Jenkins-Builds mit jenkins build libelektra please . Entschuldigen Sie die Unannehmlichkeiten.

In #3234 schlug @raphi011 vor:

imo das ist wirklich dringend, die schlaffheit und langsamkeit der tests macht es schwierig, wenn nicht unmöglich, änderungen vorzunehmen, wenn man so lange warten muss, um sie zu überprüfen.

Ich stimme zu, dass es wirklich dringend ist, aber @Mistreatment tut bereits, was er kann.

Vielleicht können wir den Build-Server also sparsamer einsetzen und nur bauen, wenn wir wirklich denken, dass der PR bald zusammengeführt wird. Unnötige Builds sollten abgebrochen werden.

Oder wie wäre es (vorübergehend) das automatische Erstellen von PRs beim Pushen von Änderungen zu stoppen (so dass der Build nur mit jenkins build libelektra please beginnt)? @Misshandelt weißt du, wie man Jenkins dazu umkonfiguriert (ich habe die Option nicht gefunden)?

Ich habe auch das Gefühl, dass jenkins build libelektra please im Moment nicht funktioniert, zumindest hat es bei diesem Build nicht funktioniert: https://github.com/ElektraInitiative/libelektra/pull/3073 leeren Commit, um die Pipeline zu starten.

Cleanup-Cronjob implementiert und Kernel-Backport auf a7 und v2 aktualisiert. Es gibt ein ziemliches Changelog für den Kernel, es wird beim nächsten Neustart aktiv sein.

Vielen Dank! Ist der "alte" Backport-Kernel noch installiert, damit wir einen Fallback haben, wenn er nicht bootet?

Ja, es kann nach einem erfolgreichen Booten in den neuen Kernel entfernt werden.

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on i7-debian-buster

docker login failed

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3244/1/pipeline

Ich habe i7 für eine manuelle Bereinigung, ein Kernel- und Docker-Upgrade deaktiviert. Jemand hat i7 aktiviert, während ich daran gearbeitet habe. Alles läuft wieder.

@Piankero Ich habe deinen Build jetzt neu gestartet.

Ich habe auch das Gefühl, dass jenkins build libelektra please im Moment nicht funktioniert, zumindest hat es bei diesem Build nicht funktioniert: #3073 ich musste einen leeren Commit pushen, um die Pipeline zu starten.

funktioniert jetzt

@Misshandelt weißt du, wie man Jenkins dazu umkonfiguriert (ich habe die Option nicht gefunden)?

Ich habe der Jenkins-Konfiguration Folgendes hinzugefügt:

Automatisches SCM-Triggering unterdrücken

Hinweis an alle: Die Verwendung von "jenkins build libelektra please" ist jetzt obligatorisch, Build-Jobs starten nicht durch einfaches Pushen. Wir werden hier informieren, wenn wir diese Einstellung zurücksetzen.

@Missrated danke! Mal sehen, ob das reicht. Ich hoffe, dass Pushs zum Master immer noch die Master-Builds auslösen?

Den hetzner-Knoten zu haben wäre trotzdem sehr gut. Gibt es Probleme, wenn der Knoten von zwei Build-Servern gleichzeitig verwendet wird? Oder wenn es ein Problem ist: Ist es nicht ganz einfach, den CT einfach zu klonen?

@Missrated danke! Mal sehen, ob das reicht. Ich hoffe, dass Pushs zum Master immer noch die Master-Builds auslösen?

master-Zweig ist jetzt eine Ausnahme von der folgenden Regel:

Automatisches SCM-Triggering unterdrücken

Wie für

Den hetzner-Knoten zu haben wäre trotzdem sehr gut. Gibt es Probleme, wenn der Knoten von zwei Build-Servern gleichzeitig verwendet wird? Oder wenn es ein Problem ist: Ist es nicht ganz einfach, den CT einfach zu klonen?

Ich habe ein neues CT (hetzner-jenkinsNode3) hinzugefügt.

konnte das Repo nicht klonen: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

Hat das vielleicht etwas mit dem neuen Knoten zu tun? (wilde Vermutung)

Hat das vielleicht etwas mit dem neuen Knoten zu tun? (wilde Vermutung)

dieser Fehler ist auf a7

dieser Fehler ist auf a7

soooo.. noch einmal versuchen?

soooo.. noch einmal versuchen?

Ja, ich glaube nicht, dass es noch einmal passieren wird..

Ich werde es für Sie wiederholen.

@Missulated Ich denke, wir können wieder automatische Builds starten. Aber schauen Sie sich bitte zuerst #3160 an.

eine ahnung warum das scheitern sollte?

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

eine ahnung warum das scheitern sollte?

Klingt nach einem vorübergehenden Problem, die URL ist derzeit über die Build-Agenten zugänglich.

Auf lange Sicht wäre es großartig, solche Abhängigkeiten in den Docker-Images einzurichten, um zu vermeiden, dass sie für jeden Build wiederholt heruntergeladen werden. Das sollte auch Build-Fehler aufgrund von vorübergehend nicht verfügbaren Paketen, wie Sie oben erwähnt haben, verhindern.

Na dann.. jenkins build libelektra please der dritte

Ja, genau aus diesem Grund haben wir alle Abhängigkeiten direkt in den Docker-Images. Ich habe #3251 erstellt

Ich habe v2 und a7 zum Neustart offline genommen.

@markus2330 Wenn Sie die Möglichkeit haben, aktivieren Sie Hyperthreading auf a7 .

v2 ist wieder hoch, auf a7 gibt es noch einen Buildjob.

Ich nahm Knoten und fügte sie dem neuen Server hinzu. Ich werde es über Nacht laufen lassen. Morgen werde ich die Knoten zurückgeben, wenn es weitere Fehler auf dem neuen Jenkins-Server gibt.

hetzner-jenkinsNode3 läuft weiterhin auf den alten Jenkins.

Morgen werde ich die Knoten zurückgeben, wenn es weitere Fehler auf dem neuen Jenkins-Server gibt.

Kleine Build-Fehler sind kein Grund, zurück zu wechseln. Irgendwann müssen wir die Fehler beheben, das Hin und Her ist sehr zeitaufwendig.

Was jedoch ein Hingucker sein könnte, ist, dass der neue Server nicht erreichbar ist. (Weder
http://95.217.75.163:8066 oder ssh). Ich habe den Netzschalter gedrückt, mal sehen, ob die Maschine neu startet. Wir sollten jedoch untersuchen, was das Problem war.

http://95.217.75.163 :8066

Wenn es Zeit ist, aktivieren Sie bitte TLS mit letsencrypt, damit wir keine Anmeldeinformationen preisgeben und uns verschiedenen anderen Problemen aussetzen?

Vielen Dank für die Eingabe! Ich würde vorschlagen, dass wir dies sofort tun, wenn wir build.libelektra.org wechseln. Ansonsten haben wir doppelte Anstrengungen.

Ist dieser Fehler bekannt? Caught the following exception: null

Anscheinend ist die Formatierungsprüfung fehlgeschlagen und die anderen Builds wurden beendet.

Du hast recht. Was für eine beschissene Fehlermeldung :P

@Mistreatment kannst du bitte wieder aktivieren, dass PRs automatisch erstellt werden? Aufgrund der vielen Agenten schläft der Server nun die meiste Zeit.

@Mistreatment kannst du bitte wieder aktivieren, dass PRs automatisch erstellt werden? Aufgrund der vielen Agenten schläft der Server nun die meiste Zeit.

Fertig.

Ich werde mir hetzner-jenkins1 und v2 wieder für den neuen Server ausleihen.

Sie müssen es nicht zurückgeben, ich hoffe, wir können heute den Wechsel vornehmen.

Tipp: Bei solchen Umschaltungen ist es gut, die TTL des DNS-Eintrags auf einen ungewöhnlich niedrigen Wert zu senken (zB 60 statt derzeit 21599 für build.libelektra.org). Nachdem die Änderung propagiert wurde, sollte es uns ermöglichen, den DNS-Eintrag innerhalb einer Minute statt innerhalb von Stunden zu ändern. Wenn es zu spät ist, kann es helfen, die DNS-Caches von google und opendns zu löschen, aber einige Leute werden unweigerlich die alte Ressource sehen, bis die zwischengespeicherten Einträge global ablaufen.

BEARBEITEN: Nach der Änderung sollte die TTL offensichtlich auf einen vernünftigen Wert zurückgesetzt werden, um das DNS weniger zu belasten.

Auch wenn es jetzt vielleicht zu spät ist, habe ich $TTL 3600 gewechselt (wenn wir mehrere Änderungen brauchen, bis alles funktioniert).

www-new und build-new existieren bereits und verweisen auf den neuen Server.

Ich habe jetzt doc.libelektra.org gewechselt. @Mistreatment wird die Veröffentlichung beheben. Ich werde mir www-new.libelektra.org anschauen

https://build-new.libelektra.org/ und https://www-new.libelektra.org/home sollten jetzt funktionieren.

Ich werde jetzt alle DNS-Einträge ändern.

Alle DNS-Einträge werden geändert.

Leider schlägt certbot fehl, da es mit dem alten Server zu sprechen scheint, aber dies scheint nur den Download und die Community (weniger verwendete URLs) zu betreffen.

Hoffentlich sieht jeder während/nach dem Wochenende die aktualisierten DNS-Namen.

@Mis Treated bitte aktualisieren Sie die Veröffentlichung aller Artefakte: auch für die Website. Bitte erstellen Sie eine PR, um sicherzustellen, dass alles ordnungsgemäß funktioniert.

Der alte Build-Server ist jetzt heruntergefahren.

Ich muss den neuen Server neu starten (neuer Kernel und Netzwerkbrücke hinzugefügt).

Server ist mit Linux pve 5.0.21-5-pve wieder hochgefahren.

Ich habe einen erneuten Scan aller PRs geplant.

Server offline wegen Fehlkonfiguration/Bug in pve (/etc/network/interfaces wurde von GUI gelöscht?).

Fehler war, dass das Umbenennen von Netzwerkgeräten (was durch meine Aktion in der GUI verursacht wurde) zu einem Kernel-OOPS führte:

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Der Server sollte wieder betriebsbereit sein.

Vorherige Probleme bleiben jedoch bestehen (Phrase funktioniert nicht #3268)

@Mistreatment master scheint auch nicht mehr automatisch zu bauen, ich

Ich sammle dringende Fehler in #3268. Es wäre gut, wenn Sie auch testen können, ob alles wie in doc/BUILDSERVER.md beschrieben funktioniert.

jenkins baut nicht ohne Angabe von Gründen:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Ein weiterer Build-Fehler: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

Vielen Dank für die Meldung!

@Mistreatment könntest du bitte Naginator+Plugin #2967 installieren, wie schon oft besprochen? (Bitte machen Sie einen Schnappschuss, bevor Sie Änderungen an Jenkins vornehmen.)

hetzner-jenkins1 : Festplattenkontingent überschritten

@Mistreatment könntest du bitte Naginator+Plugin #2967 installieren, wie schon oft besprochen? (Bitte machen Sie einen Schnappschuss, bevor Sie Änderungen an Jenkins vornehmen.)

Werde es heute machen

hetzner-jenkins1: Festplattenkontingent überschritten

@mpranj Ich habe das neue VM als Build-Agent hinzugefügt, während hetzner-jenkins1 verfügbar ist.

Ich habe etwas Speicherplatz auf hetzner-jenkins1 aufgeräumt, indem ich docker system prune -a und es wieder aktiviert habe.

Es scheint wieder ein Problem zu geben, dass viele Sachen nicht von docker system prune -f bereinigt werden. Diesmal war der Speichertreiber nicht btrfs sondern vfs . :verwirrt:

Ich habe die neue VM als Build-Agent hinzugefügt, während hetzner-jenkins1 ausgefallen ist.

Die Idee ist jetzt, dass wir nicht mehr den Container verwenden, sondern nur noch die VM.

Ich habe etwas Speicherplatz auf hetzner-jenkins1 aufgeräumt, indem ich docker system prune -a ausgeführt und wieder aktiviert habe.

Vielen Dank! Kann man dort auch einen Cronjob machen? (auf der VM, nicht auf dem Container).

cronjob dort machen?

Fertig.

@Mistreatment könntest du bitte Naginator+Plugin #2967 installieren, wie schon oft besprochen? (Bitte machen Sie einen Schnappschuss, bevor Sie Änderungen an Jenkins vornehmen.)

Wir müssen vom Pipeline- zum Freestyle-Job wechseln, wenn wir das Naginator-Plugin wollen. Ich werde nach Alternativen suchen.

Builds auf der VM jenkinsNode3VM schlagen derzeit fehl. Sie sind nicht in der Lage, Docker zu ziehen:

unexpected EOF
script returned exit code 1

Ich habe es vorerst deaktiviert, bis jemand das Problem beheben kann.

[cronjob] Fertig.

Dankeschön!

Wir müssen vom Pipeline- zum Freestyle-Job wechseln, wenn wir das Naginator-Plugin wollen. Ich werde nach Alternativen suchen.

Ja, gute Idee. Vielleicht ist es am besten, das einfach in unserem Jenkinsfile zu codieren. Wenn also ein problematischer Build-Job/eine problematische Phase fehlschlägt, wird er erneut versucht. Dass diese Docker-Pulls mindestens zweimal versucht werden, da dies eines der häufigsten Probleme ist.

Builds auf der VM jenkinsNode3VM schlagen derzeit fehl. Sie sind nicht in der Lage, Docker zu ziehen:

@Missulated bitte

Builds auf der VM jenkinsNode3VM schlagen derzeit fehl. Sie sind nicht in der Lage, Docker zu ziehen

Ich habe das Docker-Image behoben, das nicht gezogen werden konnte.

Vielen Dank! Es ist immer hilfreich, wenn Sie schreiben, was falsch war und wie Sie es behoben haben.

Ich habe keine Ahnung, was falsch war, ich habe das Image manuell auf dem Agenten erstellt. Da konnte der Agent es nicht ziehen.

Was Dockerfile (scripts/docker/debian/stretch) betrifft, sagt mein Visual Code dass es 2 leere Zeilen am Ende hat, aber vim sagt, dass es nur eine ist. Ich weiß nicht, ob es etwas mit dem obigen Fehler zu tun hat, vielleicht ist es nur mein VS .

Anscheinend haben wir Probleme mit unserer Docker-Registry (#3316 docker pull schlägt mit unexpected EOF fehl).

Da sich der Staub nach der Veröffentlichung gelegt hat und es keine Builds mehr gibt, würde ich vorschlagen, alles zu stoppen und zu versuchen, die Registrierung vollständig zu löschen. Danach sollten alle Bilder hoffentlich sauber neu aufgebaut werden. Ich würde die Registrierungsdaten sichern, bevor ich anfange, nur um sicherzugehen, aber ich hoffe, dass ein sauberer Start einige Fehler beseitigt, die wir hatten.

Ich warte auf einen Kommentar, ob etwas dagegen spricht, bevor ich anfange.

Ich denke, es ist ein Problem in der

(Skripte/Docker/debian/stretch)

Bild, da es das einzige ist, das versagt.

Ich habe es wieder manuell erstellt, aber mit dem Image in der Registrierung stimmt sicherlich etwas nicht.

Jenkins-Berichte: jenkinsNode3VM (offline)

@Mistreatment wäre großartig, wenn Sie eine Art der Überwachung

a7 (und damit v2 und i7 ) sind unten. Ich habe den Administrator kontaktiert.

EDIT markus2330: wieder hoch

Aufgrund eines geplanten Stromausfalls am 08.07.2020 an der TU Wien plant unser Admin, am Vortag (Dienstag 7.7) alle Build-Server herunterzufahren. Die Builds werden während dieser Zeit sehr langsam sein, daher bitte nur in dringenden Fällen an diesem Tag weiterarbeiten.

Server sind wieder online außer i7. Ich habe den Admin benachrichtigt.

Gestern Abend gab es erneut einen Stromausfall (ungeplant), daher sind jetzt alle Build-Server ausgefallen. Der Admin arbeitet daran.

EDIT 30 min später: alles, einschließlich i7, ist wieder oben :rocket:

@markus2330 es scheint, dass v2 und i7 kürzlich den Internetzugang verloren haben (möglicherweise während des Stromausfalls?). Sind Ihnen Konfigurationsänderungen bekannt, die wir hätten vornehmen müssen, da die Schnittstellen statisch konfiguriert sind?

Mir ist keine Änderung bekannt, nur dass die Rechner nach diesen zwei Stromausfällen (einer geplant, der andere ungeplant) wieder eingeschaltet wurden.

Aber du hast Recht, ich sehe auch, dass diese beiden (aber nicht a7) keine Internetverbindung mehr haben, obwohl sie erreichbar sind. Ich habe unseren Admin danach gefragt.

Vielleicht trennen wir sie von Jenkins, bis dieses Problem behoben ist?

Vielen Dank für die Kontaktaufnahme mit dem Administrator! Ich habe sowohl i7 als auch v2 getrennt, bis das Problem behoben werden kann. (Builds funktionieren sowieso nicht, da sie keine Docker-Images ziehen können)

Jemand hat vor etwa einer Woche etwas am Router geändert. Die Person wurde benachrichtigt und wird es hoffentlich bald beheben.

Lassen Sie uns sie vorerst getrennt halten.

Das Internetproblem ist nun behoben und ich habe auch die Sicherheitsupdates auf diesen Rechnern installiert.

@mpranj kannst du sie bitte wieder einschalten?

Danke @markus2330.

Alle Knoten sind jetzt wieder online.

Ich habe den Build-Server für den neuesten PVE-Kernel neu gestartet. Jenkins sollte in Kürze aufstehen.

bin umgezogen

• [ ] E-Mails zuverlässiger machen, wenn Build fehlschlägt
• [ ] Docker-Image ohne Jenkins-Benutzer
• [ ] centOS/fedora/arch Docker-Images
• [ ] centOS-Pakete
• [ ] Freebsd/Openbsd/Solaris-Build-Agenten

zu #3519 und mit #3519 oben verlinkt.

@robaerd hat nun auch Zugriff auf a7/v2/i7 und kann sich bei Problemen an den Admin wenden.

Nur ein kurzer Bericht über die Buildzeiten (Hauptpipeline libelektra ):

• mit aktiviertem a7 : 2h 29m 24s
• mit deaktiviertem a7 : 1h 35m 45s

Warum zeigt Jenkins an, dass es heruntergefahren wird? Wäre gut immer hier vorab zu lesen :wink:

Jenkins wird wegen einer vollständigen Systemsicherung und Neuformatierung der Dateisysteme von btrfs auf ext4 heruntergefahren.

Jenkins ist wieder wach

Jenkins CI wird heute ab ca. 11:15 Uhr MEZ wegen Wartungsarbeiten offline sein.

Wir werden einige Backup- und Bereinigungsaufgaben durchführen und versuchen, die Leistung von a7 zu verbessern.

Sie werden erneut benachrichtigt, wenn die Wartung beendet ist.

Jenkins CI und alle Build-Server sind wieder hochgefahren. a7 sollte jetzt viel besser funktionieren, hat aber weniger Speicherkapazität.

Bitte melden, wenn Fehler auftreten.

Jenkins CI und die Build-Agenten werden für eine kurze Wartung/Updates offline sein.

EDIT: Updates sind fertig.

Der Server ist ausgefallen, ich recherchiere.

Der Server ist wieder hoch.

Offizielle Erklärung zur Ursache: "Es gab ein Problem mit dem Netzteil im benachbarten Server, das zum Herunterfahren des Servers geführt hat; es wurde jetzt behoben."

Die SSD in a7 ist voll, sodass alle Builds darauf fehlschlagen.

Ich werde versuchen, etwas Speicherplatz freizugeben. Ist es sicher, den a7 Build-Agent vorerst von Jenkins zu trennen?

Vielen Dank, dass Sie sich damit befasst haben!

Ich werde versuchen, etwas Speicherplatz freizugeben. Ist es sicher, den a7-Build-Agent vorerst von Jenkins zu trennen?

Natürlich. Im Gegenteil, es wäre unsicher, die Verbindung aufrechtzuerhalten, wenn alle Builds fehlschlagen.

Beim Ausführen von docker system prune -a wieder etwa 50% des Speicherplatzes aufgeräumt. Vielleicht müssen wir den bestehenden Cronjob anpassen, um das Flag -a hinzuzufügen?

Das Jenkins-Haus verbraucht auch viel Platz.

Die Master-Builds (volle Pipeline mit Deb-Paketen und Website-Erstellung) scheitern irgendwie immer noch, obwohl alles grün aussieht. Irgendwelche Ideen?

Das Hochladen der fokalen Deb-Pakete nach community schlägt für die Datei elektra_0.9.3.orig.tar.gz fehl. Es ist wahrscheinlich ein Berechtigungsproblem für die Datei. Ich werde es vorerst aus dem Verzeichnis entfernen und beim nächsten Durchlauf neu erstellen lassen.

Irgendwie setzt der sshPublisher die Bühne nicht auf rot, wenn er fehlschlägt.

Vielleicht müssen wir den bestehenden Cronjob anpassen, um das Flag -a hinzuzufügen?

Gab es einen Grund, warum Sie es nicht so gemacht haben? Wenn nicht, klingt das nach einer guten Idee.

Jenkins CI und die Registry auf a7 werden für die Migration des Watchtower-Images auf eine neue Version offline sein. Sollte nur ein paar Minuten dauern.

BEARBEITEN: Updates sind fertig und Jenkins CI ist wieder aktiv

Jenkins und die Agenten werden für ein Update kurz unten sein.

EDIT: alles wurde aktualisiert und läuft wieder. Ich musste ein Problem beheben, bei dem a7 Debian-Stretch-Docker-Pakete anstelle von Buster verwendet. Ich habe auch etwas Platz aufgeräumt.

Builds schlagen fehl, da auf a7 kein Platz ist.

Die Build-Infrastruktur wird für einige Minuten für Wartungsarbeiten nicht verfügbar sein.

Die Build-Infrastruktur ist wieder verfügbar.