Libelektra: testshell_markdown_tutorial_crypto: fehlgeschlagen

@ markus2330 Dies ist auf dem Buildserver erfolgreich. Ist das ein Showstopper für dich? Dies würde sich in den Protokollen der Version widerspiegeln ( kdb run_all -v > ~elektra/$VERSION/run_all 2>&1 ).

EDIT: Ich kann versuchen, diesen Teil auf a7 / v2 zu machen, da er möglicherweise nur in meinem Szenario mit Fedora als Host (und Debian nur im Docker) fehlschlägt.

Nein, es ist definitiv kein Showstopper. Höchstwahrscheinlich liegt es einfach daran, dass eine temporäre Datei aus einem früheren Lauf noch vorhanden ist oder # 2957 doch nicht vollständig repariert ist.

Hoffentlich hat @ petermax2 Zeit, das Problem vor 0.9.2 zu beheben: wink:

@mpranj Benötigen Sie Hilfe bei

Ich kann das Problem beim Erstellen von 2bc994ae8b3f3a04396303ece106ea563764e490 von Grund auf mit Ihrem Befehl cmake von oben nicht reproduzieren.

    Start 188: testshell_markdown_tutorial_crypto 
222/235 Test #188: testshell_markdown_tutorial_crypto ...........   Passed    3.16 sec

Vielleicht ist Ihr Build-Verzeichnis irgendwie kaputt. Könnten Sie bitte versuchen, mit einem neuen (leeren) Build-Verzeichnis zu kompilieren und zu testen?

@ petermax2 danke, dass du es so schnell überprüft hast. Ich habe es mehrmals auf meinem Host-System (Fedora) und auch auf einem Debian-Buster-Docker-Container versucht. Ich habe auch das Build-Verzeichnis viele Male bereinigt.

Es ist immer möglich, dass es nur ein Problem für mich ist. Ich werde es später noch einmal überprüfen!

Hm seltsam! Ich glaube, ich habe gestern einen Debian: Stable- Container zum Bauen und Testen verwendet. Ich kann es abends noch einmal mit Fedora versuchen. Im Moment habe ich nicht so viel Zeit für die Fehlerbehebung, aber ich werde einen kurzen Blick darauf werfen.

Das Problem ist unter Fedora reproduzierbar.

The following tests FAILED:
 41 - testshell_markdown_base64 (Failed)
 56 - testshell_markdown_csvstorage (Failed)
 76 - testshell_markdown_iconv (Failed)
 78 - testshell_markdown_ini (Failed)
 93 - testshell_markdown_mini (Failed)
116 - testmod_resolver (Failed)
181 - testshell_markdown_tutorial_crypto (Failed)

Möglicherweise handelt es sich hierbei nicht um ein Krypto-Tutorial-spezifisches Problem. Ich muss nachforschen.

kdb gen-gpg-testkey kann nicht gefunden werden. Dieses Problem hängt mit # 3246 (KDB_EXEC_PATH) zusammen.

BEARBEITEN: Die Analyse ist nur für testshell_markdown_tutorial_crypto gültig. Die anderen Tests habe ich bisher nicht überprüft.

Vielen Dank, dass Sie sich dieses Problem angesehen haben!

Ich habe nicht gesehen, dass die anderen Tests fehlgeschlagen sind. Sind Sie sicher, dass dies das gleiche Problem ist? Ich habe nicht einmal mit der installierten kdb gearbeitet, sondern nur ctest mit make run_all ausgeführt.

Auf lange Sicht werden wir auch einige Fedora-Docker-Bilder hinzufügen (# 3227), um so etwas früher zu fangen.

Sind Sie sicher, dass dies das gleiche Problem ist?

Nein, wahrscheinlich verschiedene Probleme.

Auf lange Sicht werden wir auch einige Fedora-Docker-Bilder hinzufügen

Sehr gute Idee!

Ich habe meinen Beitrag von früher bearbeitet, um zu verdeutlichen, was ich mit meiner Analyse gemeint habe.

Das Problem ist nicht auf meinen Computer beschränkt. Der Test schlägt fehl, weil der folgende Aufruf von rename () fehlschlägt:
https://github.com/ElektraInitiative/libelektra/blob/263cbe69686a9f087204a7f3660b007d1de22da2/src/plugins/fcrypt/fcrypt.c#L231

Der Grund ist, dass / tmp standardmäßig ein separater Mountpoint unter Fedora ist, was bei Debian nicht der Fall war. Daher kann die Datei nicht über verschiedene Mountpunkte hinweg umbenannt werden.

Ich habe überprüft, dass dies das Problem ist, indem ich einen (sehr schmutzigen) Patch angewendet habe. Ich würde vorschlagen, es mit der Resolver-Implementierung konsistent zu halten und die temporäre Datei im selben Verzeichnis wie die Originaldatei abzulegen.

@ petermax2 was denkst du und hättest du Zeit, es mit einem richtigen Patch zu reparieren?

Das von fcrypt verwendete tmp-Verzeichnis kann über die Plugin-Konfiguration festgelegt werden.

fcrypt verwendet die Konfigurationsoption fcrypt / tmpdir, um Pfade für temporäre Dateien während der Ver- und Entschlüsselung zu generieren. Wenn keine solche Konfigurationsoption bereitgestellt wird, versucht fcrypt, die Umgebungsvariable TMPDIR zu verwenden. Wenn TMPDIR in der Umgebung nicht festgelegt ist, wird / tmp als Standardverzeichnis verwendet.

(_Source_: Plugin-Dokumentation )

Der einfachste Weg, Fedora-ähnliche Build-Jobs zu reduzieren, wäre die Verwendung eines anderen Verzeichnisses. Auf dem Build-Server kann das lokale Build-Verzeichnis verwendet werden. Was denkst du?

@ petermax2 was denkst du und hättest du Zeit, es mit einem richtigen Patch zu reparieren?

Ich kann an den Wochenenden etwas Freizeit einplanen, aber was halten Sie für eine richtige Lösung?

Ich kann an den Wochenenden etwas Freizeit einplanen, aber was halten Sie für eine richtige Lösung?

Sie müssen nichts überentwickeln. Wie ich vorgeschlagen habe, würde ich die temporäre Datei in das gleiche Verzeichnis wie die Zieldatei legen. Dies ist die Art und Weise, wie resolver tut, wenn Änderungen vorgenommen werden, sodass dies einigermaßen konsistent wäre.

Ich kann auch nur ein anderes TMPDIR für die Builds konfigurieren. Ich kann diese Änderung selbst umsetzen.

Wir werden mit allem, was Sie hier vorschlagen, gehen.

Vom Dokument umbenennen :

[EXDEV]
[CX] [Option Start] The links named by new and old are on different file systems and the implementation does not support links between file systems. [Option End]

Bearbeiten: schlägt mit sudo mit dem gleichen Fehler fehl:

213: CMD: kdb set user/tests/password 1234
213: RET: 5
213: === FAILED return value does not match expected pattern 0
213: STDERR: Sorry, module fcrypt issued the error C01100:
213: Resource: Renaming file /tmp/test.ini.571145:1586371945.946855.tmpHdGEMt to /root/.config/test.ini.571145:1586371945.946855.tmp failed. Reason: Invalid cross-device link
213: ERROR: C01100

Eine vereinfachte Lösung wäre, die Operation rename durch eine Kopie + Entfernen zu ersetzen.

Ich werde einfach ein anderes TMPDIR explizit für die Builds konfigurieren. Wenn das Problem auf Zielsystemen erneut auftritt, können wir es erneut öffnen und eine bessere Lösung finden.

Ich denke, dieses Problem könnte häufiger auftreten. Wir empfehlen sogar in der fcrypt-Dokumentation, /tmp auf einer RAM-Disk zu mounten. Wir empfehlen daher, diesen Fehler sofort auszulösen.

Ich werde versuchen, eine ordnungsgemäße Lösung bereitzustellen.

Ich werde einfach ein anderes TMPDIR explizit für die Builds konfigurieren. Wenn das Problem auf Zielsystemen erneut auftritt, können wir es erneut öffnen und eine bessere Lösung finden.

Dies ist auch eine gute Lösung für die Build-Server.

Vielen Dank, dass Sie sich damit befasst haben!

Eine vereinfachte Lösung wäre, den Umbenennungsvorgang durch Kopieren + Entfernen zu ersetzen.

Nicht um den Code zu ersetzen, sondern um dies zu tun, wenn das Umbenennen fehlgeschlagen ist. (Und um in diesem Fall auch die Quelldatei zu vernichten.) Dann haben Leute ohne RAM-Disc auf / tmp Geschwindigkeit und Leute mit RAM-Disc auf / tmp haben mehr Sicherheit.