Libelektra: Cache: KDB-Exportsystem

Natürlich, warum nicht? Es exportiert auch Versionen und andere Dinge, die für den Import nicht nützlich sind. Sie können --without-elektra hinzufügen, um den Export dieser Teile zu vermeiden.

Für den Shell-Recorder würde ich auch erwarten, dass nur das angegebene Teil gesichert und wiederhergestellt wird.

Natürlich, warum nicht?

Entfernt kdbSet sie irgendwie? Es scheint falsch, diese Schlüssel zu serialisieren, wenn sie über einen speziellen Teil der Plugin-Get-Funktionen fest codiert sind ...

Für die Versionsinformationen prüft kdbSet, ob sie identisch sind, und ignoriert kdbSet, wenn sie identisch sind. Andernfalls wird ein Fehler generiert.

Für Module (iirc) gibt es kein kdbSet, daher werden die einzustellenden Schlüssel einfach ignoriert. Iirc das "Konstanten" Plugin hat das gleiche Verhalten Es wird normalerweise system / info / elektra gemountet, also nicht in system / elektra. Vielleicht sollten wir das ändern, um --without-elektra nützlicher zu machen?

Aber trotzdem: Beide Verhaltensweisen (Ignorieren und Überprüfen auf identische Schlüssel) sollten einem Import keinen Schaden zufügen.

Für die aktuelle Situation der recht instabilen Elektra ist es also durchaus sinnvoll: Importe von System / Elektra werden abgelehnt, sofern die Version nicht identisch ist. Um diesen Fehler zu vermeiden, kann --without-elektra übergeben werden.

Nach 1.0 können wir tatsächlich entspannter sein und Importe aus Elektra-Versionen 1.0 oder höher akzeptieren. ( @mpranj was denkst du?)

Der Text muss dann angepasst werden, derzeit ist es:

kdb import system < sys
Sorry, module kdb issued the error C01320:
Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version/constants/KDB_VERSION_MICRO (expected system/elektra/version/constants/KDB_VERSION_MICRO) was tried to be modified to '1' (expected '2')

Wie auch immer, Ihre Frage gibt einen Einblick darüber, wie wir die Dokumentation von --without-elektra verbessern können. Die Idee von --without-elektra im Zusammenhang mit Import / Export ist, dass entweder:

1. Alle Internas von Elektra werden exportiert, aber dann haben wir auch die Versionsprüfung, um Elektra nicht durcheinander zu bringen.
2. Sie importieren / exportieren keine Internas von Elektra, daher spielt die Version von Elektra keine Rolle (nur die Version des Speicher-Plugins)

Nach 1.0 können wir tatsächlich entspannter sein

Ich stimme den Vorschlägen zu.

Wie @kodebach erwähnte, ist es irgendwie seltsam, dass dies gerade in # 3115 erschien und vorher nicht erschien. Während das Hinzufügen von --without-elektra wahrscheinlich an erster Stelle für das Sichern und Wiederherstellen vorhanden sein sollte, scheint es dennoch, dass der PR ein gewisses Verhalten geändert hat.

@kodebach hast du den Cache für diese Tests wieder aktiviert? Ich möchte warten, bis der Rest der PR erledigt ist, damit ich mmapstorage und Cache reparieren kann. Ich habe solche / ähnliche Fehler gesehen ( Postcondition of backend was violated: drop key [...] not belonging to [...] ), während der Cache nicht korrekt implementiert wurde.

Haben Sie den Cache für diese Tests erneut aktiviert?

Ja, der Cache ist vollständig aktiviert.

so kann ich mmapstorage und cache reparieren

mmapstorage funktioniert bereits. Es stellte sich heraus, dass ich irgendwo ein key anstelle von ukey .

Abgesehen vom Problem mit dem globalen Unmount-Test scheint auch der Cache zu funktionieren. Zuletzt habe ich überprüft, dass der Fehler nicht aufgetreten ist, wenn der Cache nicht kompiliert wurde.

Ich habe Teile von kdbGet , elektraCacheGet und verwandten Funktionen geändert. Es ist wahrscheinlich, dass ich etwas kaputt gemacht habe, aber da die Dinge, die ich geändert habe, wahrscheinlich nach # 2969 wieder geändert werden müssen, denke ich nicht, dass Sie jetzt einen Blick darauf werfen müssen.

OK. Ich schlage vor, wenn der Cache + mmapstorage die Probleme verursacht, lassen Sie ihn einfach bis zum Ende deaktiviert und wir aktivieren dann die Anpassung.

Die PR ist eine ziemlich grundlegende Änderung, daher ist es viel einfacher, wenn Sie nicht aufgrund eines fehlerhaften Cache-Verhaltens stecken bleiben. Wenn es im Grunde fertig ist, aktiviere einfach den Cache erneut und pinge mich an, damit ich einen Blick darauf werfen und die Reste reparieren kann.

@mpranj : Ich habe dich zugewiesen, da dies mit dem Cache zusammenhängt.

Ich kann auf dem aktuellen Master nichts Ähnliches reproduzieren. Ich kann dort nicht viel tun, wenn nicht jemand weiß, wie man es dort reproduziert, aber ich vermute, dass es auf dem Master nicht vorhanden ist.

Auf dem Zweig von # 3115 erhalte ich die Fehler wie beschrieben. @kodebach sollte ich da

Ich denke, es lohnt sich nicht, an # 3115 zu arbeiten, bis # 2969 und die zugehörigen PRs zusammengeführt werden. Danach werde ich neu starten und versuchen, die PR zu beenden. Ich möchte so wenig wie möglich neu gründen, da Sie grundsätzlich alle Commits auf alles überprüfen müssen, was auf der Syntax von Schlüsselnamen beruht, um eine ordnungsgemäße Basis zu gewährleisten.

Wenn Sie möchten, können Sie natürlich nach dem Fehler in der aktuellen Version der PR suchen. Soweit ich mich erinnere, habe ich dies jedoch bei master versucht, bevor ich das Problem erstellt habe. Vielleicht wurde es in der Zwischenzeit behoben.

Ich denke, es lohnt sich nicht, an # 3115 zu arbeiten, bis # 2969 und die zugehörigen PRs zusammengeführt werden.

OK danke! Warten wir dann ab und überprüfen Sie dieses Problem, nachdem die zugehörigen PRs zusammengeführt wurden!

Ist es möglich, Probleme zu markieren, die auf PRs warten? Ich habe den Titel vorerst geändert.

Ich habe es heute tatsächlich geschafft, dies auf master zu reproduzieren. Insbesondere habe ich scripts/docker/fedora/32/Dockerfile (technisch gesehen von # 3447, nicht von master , aber die Datei ist dieselbe und vollständig eigenständig). Ich habe dann einen Container mit gestartet

docker run -it -w /home/jenkins elektra-fedora-32:latest

und innerhalb des Containers liefen die folgenden Zeilen:

git clone https://github.com/ElektraInitiative/libelektra
cd libelektra && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DKDB_DB_SPEC="$PWD/config/spec" -DKDB_DB_SYSTEM="$PWD/config/system" -DKDB_DB_USER="cdbg-1/.config" -DCMAKE_INSTALL_PREFIX="$PWD/install" -DINSTALL_SYSTEM_FILES=OFF -DENABLE_DEBUG=ON -DENABLE_LOGGER=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DPLUGINS="ALL;-lua;-ccode;-tcl" -DBINDINGS="ALL" -DCOMMON_FLAGS="-Werror"
make -j 24
bin/kdb export system toml

Die Ausgabe des letzten Befehls war:

elektra.modules.cache = "cache plugin waits for your orders"
elektra.modules.cache.exports = ""
elektra.modules.cache.exports.close = "(binary)"
elektra.modules.cache.exports.get = "(binary)"
elektra.modules.cache.exports.open = "(binary)"
elektra.modules.cache.exports.set = "(binary)"
elektra.modules.cache.infos = "Information about the cache plugin is in keys below"
elektra.modules.cache.infos.author = "Mihael Pranjic <[email protected]>"
elektra.modules.cache.infos.licence = "BSD"
elektra.modules.cache.infos.metadata = ""
elektra.modules.cache.infos.needs = ""
elektra.modules.cache.infos.placements = "pregetcache postgetcache"
elektra.modules.cache.infos.provides = ""
elektra.modules.cache.infos.recommends = ""
elektra.modules.cache.infos.status = "maintained unittest shelltest specific global"
elektra.modules.cache.infos.version = 1
elektra.modules.dump = "dump plugin waits for your orders"
elektra.modules.dump.config.needs.fcrypt.textmode = 0
elektra.modules.dump.exports = ""
elektra.modules.dump.exports.get = "(binary)"
elektra.modules.dump.exports.serialise = "(binary)"
elektra.modules.dump.exports.set = "(binary)"
elektra.modules.dump.exports.unserialise = "(binary)"
elektra.modules.dump.infos = "Information about the dump plugin is in keys below"
elektra.modules.dump.infos.author = "Markus Raab <[email protected]>"
elektra.modules.dump.infos.licence = "BSD"
elektra.modules.dump.infos.metadata = ""
elektra.modules.dump.infos.needs = ""
elektra.modules.dump.infos.placements = "getstorage setstorage"
elektra.modules.dump.infos.provides = "storage/dump storage dump"
elektra.modules.dump.infos.recommends = ""
elektra.modules.dump.infos.status = "productive maintained conformant unittest tested nodep -1000 default"
elektra.modules.dump.infos.version = 1
elektra.modules.list = "list plugin waits for your orders"
elektra.modules.list.exports = ""
elektra.modules.list.exports.addPlugin = "(binary)"
elektra.modules.list.exports.close = "(binary)"
elektra.modules.list.exports.deferredCall = "(binary)"
elektra.modules.list.exports.editPlugin = "(binary)"
elektra.modules.list.exports.error = "(binary)"
elektra.modules.list.exports.findplugin = "(binary)"
elektra.modules.list.exports.get = "(binary)"
elektra.modules.list.exports.mountplugin = "(binary)"
elektra.modules.list.exports.open = "(binary)"
elektra.modules.list.exports.set = "(binary)"
elektra.modules.list.exports.unmountplugin = "(binary)"
elektra.modules.list.infos = "Information about the list plugin is in keys below"
elektra.modules.list.infos.author = "Thomas Waser <[email protected]>"
elektra.modules.list.infos.licence = "BSD"
elektra.modules.list.infos.needs = ""
elektra.modules.list.infos.placements = "pregetstorage procgetstorage postgetstorage postgetcleanup presetstorage presetcleanup precommit postcommit prerollback postrollback"
elektra.modules.list.infos.provides = ""
elektra.modules.list.infos.status = "unittest nodep libc configurable global"
elektra.modules.list.infos.version = 1
elektra.modules.resolver_fm_hpu_b = "resolver_fm_hpu_b plugin waits for your orders"
elektra.modules.resolver_fm_hpu_b.constants = ""
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_BASE = "fm"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_SYSTEM = "b"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_USER = "hpu"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_DIR = ".dir"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_HOME = "/home"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SPEC = "/home/jenkins/libelektra/build/config/spec"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SYSTEM = "/home/jenkins/libelektra/build/config/system"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_USER = "cdbg-1/.config"
elektra.modules.resolver_fm_hpu_b.exports = ""
elektra.modules.resolver_fm_hpu_b.exports.checkfile = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.close = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.commit = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.error = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.filename = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.freeHandle = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.get = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.open = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.set = "(binary)"
elektra.modules.resolver_fm_hpu_b.infos = "All information you want to know is in keys below"
elektra.modules.resolver_fm_hpu_b.infos.author = "Markus Raab <[email protected]>"
elektra.modules.resolver_fm_hpu_b.infos.licence = "BSD"
elektra.modules.resolver_fm_hpu_b.infos.needs = ""
elektra.modules.resolver_fm_hpu_b.infos.placements = "rollback getresolver setresolver commit"
elektra.modules.resolver_fm_hpu_b.infos.provides = "resolver"
elektra.modules.resolver_fm_hpu_b.infos.status = "productive maintained specific unittest tested libc nodep configurable default"
elektra.modules.resolver_fm_hpu_b.infos.version = 1
elektra.version = "Below are version information of the Elektra Library you are currently using"
elektra.version.constants = ""
elektra.version.constants.KDB_VERSION = "0.9.2"
elektra.version.constants.KDB_VERSION_MAJOR = 0
elektra.version.constants.KDB_VERSION_MINOR = 9
elektra.version.constants.KDB_VERSION_PATCH = 2
elektra.version.constants.SO_VERSION = 4
elektra.version.infos = "All information you want to know"
elektra.version.infos.author = "Markus Raab <[email protected]>"
elektra.version.infos.description = "Information of your Elektra Installation"
elektra.version.infos.licence = "BSD"
elektra.version.infos.version = 1

(HINWEIS: Ich habe die .description -Schlüssel aus der Ausgabe entfernt, da sie die Zeichenfolge ``` und daher die Markdown-Formatierung von Github aufheben.)

IMO sollte die Ausgabe tatsächlich leer sein, da alle Schlüssel von der spezifischen Elektra-Installation abgeleitet sind und niemals in eine KDB importiert werden sollten. Möglicherweise könnte das Exportieren der version.constants -Schlüssel sinnvoll sein, wenn kdb import ordnungsgemäß ignoriert (die anderen version -Schlüssel sollten ebenfalls nicht exportiert werden).

~ Die Postcondition of backend was violated: drop key system:/elektra/modules/cache/infos/licence not belonging to "system:/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint Probleme treten nur in # 3447 und nur für das cache Plugin auf. Es gibt also immer noch einen Fehler in # 3447. Das Beheben dieses kdb export -Problems würde das Problem jedoch ebenfalls beseitigen. ~

KORREKTUR: Die Nachbedingungsprobleme treten tatsächlich auch im Docker-Container auf.

In dem Container von oben rannte ich (direkt nach den anderen Sachen):

ctest -R kdb_global_umount --output-on-failure

Danach meldet jeder kdb Befehl, der versucht, auf die KDB zuzugreifen, viele postcondition Warnungen, z. B. kdb ls system .

Wenn ich versuche, kdb rm -r system auszuführen, erhalte ich außerdem:

Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version (value Below are version information of the Elektra Library you are currently using) tried to be removed

Dass kdb rm -r system fehlschlägt, ist absichtlich. Was hast du erwartet?

Ich muss jedoch zugeben, dass die Fehlermeldung ziemlich schlecht ist (auch grammatikalisch und semantisch: Der Benutzer hat etwas versucht, nicht den Schlüssel).

Was hast du erwartet?

Um fair zu sein, macht kdb rm -r system in einem realen System nicht viel Sinn. Bei einem Entwicklungssetup kann dies nützlich sein (das manuelle Löschen der Dateien ist jedoch auch nicht schwierig).

Ich muss allerdings zugeben, dass die Fehlermeldung ziemlich schlecht ist

Ich denke, das hat mich am meisten verwirrt. Wenn die Nachricht so etwas wie "Entfernen ... nicht erlaubt" lautete, hätte ich verstanden, dass ich etwas falsch gemacht habe. Zusätzlich haben wir AFAIK Interface Errors als Fehler im Code definiert und nicht als etwas, das vom Benutzer verursacht wurde.

Was das version Plugin und die schreibgeschützten Plugins im Allgemeinen betrifft: Ich denke, es sollte eine Möglichkeit geben, diese Fehler von schreibgeschützten Plugins zu ignorieren, wenn Sie kdb rm (vielleicht kdb rm -rf aufrufen ).
In gewisser Hinsicht ist das "Entfernen" von schreibgeschützten Schlüsseln sinnvoll, zumindest wenn wir alles auf einmal unter dem schreibgeschützten Mountpunkt entfernen. kdb rm -r some/mountpoint sollte die gesamte zugrunde liegende Konfigurationsdatei für some/mountpoint entfernen, dh die Nachbedingung ist, dass keine Konfigurationsdatei vorhanden ist. Da schreibgeschützte Plugins (zumindest solche, die wie version funktionieren) keine Konfigurationsdateien haben, wird die Nachbedingung automatisch erfüllt.

Bei einem Entwicklungssetup kann dies hilfreich sein

Für die Entwicklung gibt es kdb reset .

Wenn in der Nachricht so etwas wie "Entfernen ... nicht erlaubt" steht

Ich stimme vollkommen zu! Was ist mit # 3498?

vielleicht kdb rm -rf

Ich finde -f verwirrend, da Sie es nicht erzwingen, sondern nur ignorieren können, also wäre --without-elektra imho besser geeignet?

sollte die gesamte zugrunde liegende Konfigurationsdatei für entfernen

Ja, das ist der Fall und der Resolver kümmert sich darum.

Die Nachbedingung ist automatisch erfüllt.

Naja, es gibt auch die Nachbedingung, dass nach kdb rm key kdb get key ein nicht gefundener Schlüssel zurückgegeben wird. Diese Nachbedingung wäre nicht erfüllt.

Das Ändern der Fehlermeldung sollte ausreichen

Gibt es jetzt noch Fehler, die in dieser Ausgabe beschrieben werden?

AFAIK dieser und der nächste Kommentar (dh das ursprüngliche Problem) sind noch ungelöst: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Entschuldigung, anscheinend habe ich dieses Problem zunächst falsch verstanden. Lassen Sie mich noch einmal zusammenfassen, um zu sehen, ob ich es jetzt richtig verstehe.

Aus Sicht des Caches möchten wir die mmap-Dateien so oft wie möglich wiederverwenden. Wenn also jemand kdbGet auf "system/this" anruft und der Mountpoint tatsächlich "system" , bleiben wir "system" vollständig bestehen. Wenn dann jemand kdbGet auf "system/other" aufruft, ist der Cache bereits vorhanden, was die Dinge um einiges beschleunigt. Grundsätzlich erstellen wir eine MMAP-Cache-Datei pro Mountpunkt, speichern jedoch ALLE Schlüssel unterhalb des Mountpunkts.

Wenn ich das Problem jetzt richtig verstehe, ist Ihr Punkt, dass das Zwischenspeichern von "system/elektra/modules" und gleichem beides ist:

1. fehlerhaft und
2. irrelevant, da das Abrufen dieser Schlüssel sowieso schnell ist.

BEARBEITEN: Derzeit werden durch das Abrufen des Caches ksAppend und andere Vorgänge vollständig vermieden. So bewahren wir das OPMPHM und alles. Wenn wir anfangen, "system/elektra/modules" an den Rest des System-Mountpoints anzuhängen, verlieren wir mit Sicherheit etwas an Leistung. Vielleicht ist es für den System-Namespace nicht relevant, aber es würde sicherlich die Leistung beeinträchtigen, wenn wir überall solche Edge-Cases haben.

Hinweis: Ich habe die Kommentare zu kdb rm system als gelöst markiert, sodass sie von Github ausgeblendet werden. Das sollte dieses Problem etwas klarer machen.

Wenn ich das Problem jetzt richtig verstehe, ist Ihr Punkt, dass das Zwischenspeichern von "system/elektra/modules" und gleichem beides ist:

1. fehlerhaft und
2. irrelevant, da das Abrufen dieser Schlüssel sowieso schnell ist.

Nur sie zwischenzuspeichern ist ja falsch, aber wir könnten sie trotzdem zwischenspeichern, solange es eine Logik gibt, um zu erkennen, dass sich die Schlüssel geändert haben. Ich kann die Geschwindigkeit nicht kommentieren, aber die Verwendung des Caches ist möglicherweise immer noch schneller. Wie Sie sagten, vermeidet es ksAppend und vermeidet auch viele Aufrufe von Plugins.

In der ursprünglichen Ausgabe geht es nur um das Verhalten von kdb export . Die Ausgabe sollte niemals Schlüssel unter system/elektra/modules oder system/elektra/version , da diese spezifisch für die Elektra-Installation sind und nicht in eine andere KDB importiert werden sollten.

Ich habe nicht untersucht, woher diese Schlüssel stammen, daher bin ich mir nicht sicher, ob das Plugin cache tatsächlich hier involviert ist. Die beste Lösung könnte darin bestehen, diese Teile einfach immer ksCut in kdb export . Auf diese Weise kann das Problem nicht erneut auftreten, wenn sich etwas ändert.

Es gibt auch das Problem "Nachbedingung des Backends wurde verletzt". Mein bisheriges Verständnis ist, dass dieses Problem durch kdb export , die Schlüssel in system/elektra/modules , aber ich bin zu 100% sicher:

Wenn Sie die Schritte unter https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 ausführen und dann ausführen

ctest -R kdb_global_umount --output-on-failure

bin/kdb ls system

(wie ich im nächsten Kommentar sagte), erhalten Sie viele:

Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint

Dies ist eigentlich der einzige Verweis auf das Plugin cache . AFAICT das ist was hier passiert:

• Das "Backup and Restore" -Verfahren des Tests verwendet kdb export und kdb import .
• Irgendwie führt dies dazu, dass die Schlüssel von system/elektra/modules/cache dauerhaft in die Datei elektra.ecf werden.
• Wenn wir dann irgendeine Form von kdbGet über zB kdb ls system aufrufen, haben wir das Problem.
• Ich bin mir nicht sicher, was genau dieses Problem ist, aber ich bin mir ziemlich sicher, dass ein system/elektra/modules/... Schlüssel niemals auf die Festplatte geschrieben werden sollte.
• Die einzige Möglichkeit zur Wiederherstellung besteht darin, die system/elektra/modules/... Schlüssel manuell von elektra.ecf zu entfernen.

Möglicherweise muss dies in kdb import behoben werden, nicht im Cache.

Vielen Dank, dass Sie dies gemeldet haben!

Der Cache speichert diese (beliebigen) Schlüssel definitiv, wenn sie im zurückgegebenen KeySet von kdbGet . Es gibt keine Ausnahmen für den Cache. Wie Sie bereits sagten, ist es jedoch nicht sinnvoll, diese Schlüssel für kdb import zuzulassen. Ich werde sehen, ob ich dies anhand Ihrer Beschreibung reproduzieren und beheben kann.

Wenn das Problem nur bei Verwendung von kdb import auftritt, würde ich diese Sonderschlüssel beim Import einfach löschen.

Ich stimme @mpranj zu, dass der Cache alles vollständig zurückgeben sollte.

Die Ausgabe sollte niemals Schlüssel unterhalb von system / elektra / modules oder system / elektra / version enthalten, da diese spezifisch für die Elektra-Installation sind und nicht in eine andere KDB importiert werden sollten.

Das Exportieren dient nicht nur zum Importieren, sondern auch zum Anzeigen mehrerer Schlüssel / Werte für einen Benutzer. Mit kdb export system/elektra/version/constants simpleini ist nichts falsch, um alle Versionsinformationen anzuzeigen.

Ich habe nicht untersucht, woher diese Schlüssel stammen, daher bin ich mir nicht sicher, ob das Cache-Plugin tatsächlich hier involviert ist. Die beste Lösung könnte darin bestehen, diese Teile beim kdb-Export immer ksCut. Auf diese Weise kann das Problem nicht erneut auftreten, wenn sich etwas ändert.

Solch ein ksCut passiert, wenn Sie --without-elektra sagen. Was wir tun könnten, ist die Standardeinstellung zu ändern: elektra standardmäßig ausschließen, außer wenn explizit importiert / exportiert / elektra oder --with-elektra gesagt wird.

Die Nachbedingung des Backends wurde verletzt

Dies scheint ein nicht verwandter Fehler zu sein. (Möglicherweise verwendet der Shellrecorder nicht --without-elektra ). https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 sieht jedoch so aus, wie es sein sollte. (Ich kann nicht reproduzieren, ich bekomme Error response from daemon: pull access denied for elektra-fedora-32, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. )

Ich kann nicht reproduzieren

Wir haben dieses Bild nicht im Docker Hub veröffentlicht.

Voraussetzung hierfür ist, dass er das Docker-Image aus scripts/docker/fedora/32/Dockerfile und den Build mit -t elektra-fedora-32:latest markiert, wenn docker build .

Etwas wie:

cd scripts/docker/fedora/32/
docker build -t elektra-fedora-32:latest -f ./Dockerfile .

Danke, ja, ich kann die Postcondition of backend was violated -Probleme jetzt auf dem Master reproduzieren (wie von @kodebach im Docker-Image beschrieben und dann mit globalen Mount-Befehlen):

 Sorry, 17 warnings were issued ;(
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/close not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/get not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/open not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/set not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/author not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/description not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/metadata not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/needs not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/placements not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/provides not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/recommends not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/status not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/version not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint

Das Problem hat eindeutig nichts mit kdb export wie es auch auftritt, z. B. mit kdb ls oder kdb cache clear .

Interessanterweise hilft kdb cache clear nicht, aber es könnte immer noch ein Problem des Caches sein (da kdb Tools zuerst KDB , um ihre Konfiguration zu erhalten).

@mpranj hast du eine idee

Was wir tun könnten, ist die Standardeinstellung zu ändern: elektra standardmäßig ausschließen, außer wenn explizit importiert / exportiert / elektra oder --with-elektra gesagt wird.

Ja, das wäre definitiv eine bessere Lösung. Idealerweise würden wir auch zwischen system/elektra/modules / system/elektra/version und dem Rest von system/elektra . Die Mountpoint-Konfiguration und die globale Plugin-Konfiguration sind viel nützlicher als die Module und Versionsschlüssel (die zur Laufzeit generiert werden).

Das Problem hat eindeutig nichts mit kdb export da es auch auftritt, z. B. mit kdb ls oder kdb cache clear .

Wie ich bereits sagte, ist das "Postcondition" -Ding wahrscheinlich ein Fehler in kdb import .

Interessanterweise hilft kdb cache clear nicht

Warum sollte es? Wie gesagt, das Problem ist, dass system/elektra/modules Schlüssel in elektra.ecf gespeichert sind. Wenn Sie meine obigen Schritte befolgt haben (speziell die gleichen cmake -Optionen verwendet haben), können Sie dies durch Ausführen sehen

cat config/system/elektra.ecf

innerhalb des Verzeichnisses build .

Wie ich bereits sagte, ist das "Postcondition" -Ding wahrscheinlich ein Fehler beim kdb-Import.

Da kdb import nicht viel mehr tut, als ein KeySet zu erstellen und kdbSet aufzurufen, befürchte ich, dass das Problem irgendwo in kdbSet . Das korrekte Verhalten beim Speichern von Daten in system/elektra/modules muss ein Fehler oder ein Verwerfen sein und darf definitiv nicht bestehen bleiben. Aber offensichtlich ist dies nicht das Verhalten:

kdb set system/elektra/modules/NOTALLOWED
kdb ls system/elektra/modules
#> system/elektra/modules/NOTALLOWED
#> system/elektra/modules/cache
...

Wenn also ein NOTALLOWED-Plugin gemountet wird, haben wir das hier beschriebene Problem. Wir brauchen also kdbSet um bei Versuchen, an system/elektra/modules zu schreiben,

Eigentlich müssen wir die Semantik der gesamten /elektra -Hierarchie definieren, was wahrscheinlich eine größere Aufgabe ist ...

Das Problem ist, dass die Schlüssel system / elektra / modules in elektra.ecf gespeichert sind

Entschuldigung, ich habe es nicht gesehen, als ich zwischen den Kommentaren herumsprang und versuchte, es zu reproduzieren.