![](https://seccdn.libravatar.org/avatar/f1e842addddd01a15c1e7a7b9aea1650.jpg?s=120&d=mm&r=g)
On Sun, 25 Dec 2022, Michael Behrens wrote:
Am 25.12.22 um 13:28 schrieb Christian Boltz:
Das ist ein (inzwischen) bekanntes Problem, Details gibt es in https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...
Hallo Christian,
danke, ich habe eben mal 'mc' und 'mc-lang' deinstalliert, dann kommt der Fehler nicht mehr. Nach Wiederinstallation von 'mc' (ohne oder mit 'mc-lang') ist er aber wieder da. Das Paket heißt 'mc-4.8.27-bp153.2.3.1.x86_64'.
Das Problem tritt übrigens auch bei einer ssh-Verbindung von Leap 15.3 nach Leap 15.3 auf, sobald man diese openssh-Updates installiert hat.
Ja, auch auf Leap 15.3 existiert bei mir (vielleicht erst nach dem ssh Update?) die Datei /etc/profile.d/openssh-dbus.sh in der dbus-update-activation-environment --systemd --all ausgeführt wird. Ein Kommando dbus-update-activation-environment --systemd --all --verbose gibt auf meinem Leap 15.3 oder 15.4 Zielrechner u.a. die Zeile dbus-update-activation-environment: setting BASH_FUNC_mc%%=() { . /usr/share/mc/mc-wrapper.sh } aus, die wohl zu der Warnung dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments führt. Diese etwas "seltsame" Variable naiv mit unset BASH_FUNC_mc%% löschen zu wollen, klappte aber nicht, auch nicht in Hochkomma gesetzt ("not a valid identifier"). Ich habe dann nach Dateien aus dem installierten 'mc' Paket gesucht, die "mc-wrapper.sh" enthalten und bin auf die beiden identischen Dateien /etc/profile.d/mc.sh /usr/share/mc/mc.sh gestossen, die jeweils folgenden Inhalt haben: # Don't define aliases in plain Bourne shell [ -n "${BASH_VERSION}${KSH_VERSION}${ZSH_VERSION}" ] || return 0 mc() { . /usr/share/mc/mc-wrapper.sh } if [ -n "$BASH_VERSION" ] then export -f mc fi Da der betroffene Benutzer die bash als Default-Shell benutzt, habe ich als Minimaltest einmal den Variablen-Export durch Auskommentieren (als "root") in /etc/profile.d/mc.sh verhindert, was tatsächlich die Warnung zum Verschwinden brachte. Da ich 'mc' an sich gar nicht benutze (kann mich an eine Installation gar nicht erinnern), hätte ich natürlich wie Du die betreffenden Pakete auch gleich löschen kännen, ich war nur noch etwas neugierig, wer bzw. was mir genau das nervende und etwas verunsichernde kleine Problem eingebrockt hat. Jens