LXC-Betriebssystem-Container mittels virt-manager unter Opensuse Leap 42.2 – I

Das Thema "Container" ist wegen der guten Ressourcenauslastung auch für KMUs von Interesse. Will man sich dem Thema "Container" unter Linux annähern, ohne sich gleich mit Docker zu befassen, kann man alternativ zu LXC greifen. Dafür sprechen sogar ein paar gute Gründe:

  • LXC ist erprobt; viele Distributionen bringen LXC mit.
  • Ubuntu setzt mit der LXD-Umgebung explizit auf dieses Container-Format.
  • LXC (und LXD) setzen mehr auf Container für vollständige Betriebssysteme, Docker dagegen auf modulare Container für Einzelapplikationen. Wären da nicht diverse Sicherheitsthemen, so könnten performante, ressourcenschonende LXC-Container virtuelle (Linux-) Maschinen unter KVM ersetzen. Die potentielle Packungsdichte von LXC-Containern auf einem Host ist deutlich höher als die von KVM/qemu-VMs.
  • LXC erlaubt einen unpriviligierten Container-Betrieb - der Gewinn an Sicherheit erfordert allerdings Mühe im Container-Setup. Aber immerhin ...
  • Auch in kleinen Umgebungen will man Container neben virtuellen KVM-Maschinen gerne grafisch verwalten und überwachen. Als handliche und vor allem erschwingliche Werkzeuge bleiben da eigentlich nur "virtlib/virt-manager" (rudimentäre Minimalausstattung) und "Proxmox" für den professionellen Einsatz übrig. Beide Tools unterstützen LXC-Container und erlauben zudem das Anlegen mehr oder weniger komplexer Storage-Konfigurationen.
  • Läuft der gewünschte Container erst mal, darf man sich über eine sehr gute Performance freuen (zumindest im kleinskaligen Betriebsumfeld).

Am letzten Wochenende wollte ich einen LXC-Container unter Opensuse Leap einfach mal ein wenig austesten. Für das Erstellen wollte ich das Gespann "libvirt/virt-manager" heranziehen. Die Anlage eines sog. "Betriebssystem-Containers" erwies sich damit unter Leap 42.2 aber als kleineres Abenteuer - selbst bei einer rein lokalen Storage-Konfiguration. Dieser und der nachfolgende Artikel sollen Einsteigern helfen, die ersten Hürden zu überwinden.

Begrifflichkeiten und eine Warnung

Ich gehe nachfolgend aus Platzgründen nicht weiter auf die grundlegenden Unterschiede zwischen Containern und voll- oder paravirtualisierten "Virtuellen Maschinen" [VMs] ein. Wer sich Container-Technologie im Schnelldurchgang reinziehen will, sei auf den Foliensatz https://de.slideshare.net/jpetazzo/anatomy-of-a-container-namespaces-cgroups-some-filesystem-magic-linuxcon verwiesen.

Für den vorliegenden Blog-Beitrag ist die Vorstellung hilfreich, ein Container sei so etwas wie eine aufgeblasene chroot-Umgebung, die Prozesse in einer vom restlichen Betriebssystem "isolierten" Umgebung bündelt.

Auch die Suse-Dokumentationen zur Anlage von Containern
https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html#sec.lxc.setup.container.app
https://doc.opensuse.org/documentation/leap/virtualization/book.virt_color_en.pdf
merken an:

Conceptually, containers can be seen as an improved chroot technique. The difference is that a chroot environment separates only the file system, whereas containers go further and provide resource management and control via cgroups."

Die vom Container-Nutzer ausgelösten Prozesse laufen direkt unter dem Kernel des Hosts - und nicht wie in einer VM unter einem eigenem Kernel für die emulierte HW). Für die Container-Isolation sorgen unter Linux cgroups und vor allem strong>namespaces (seit Kernelversion 3.8):

  • "cgroups" bündeln Prozesse in Bezug auf die limitierte Nutzung von System-Ressourcen auf dem Host.
  • "namespaces" sorgen hingegen dafür, dass Prozesse und ihre Kinder eine separate Sicht und einen abgegrenzten Zugriff auf ihre jeweilige Betriebssystem-Umgebung erhalten.

Vor allem "namespaces" sorgen also für eine (hoffentlich !) hinreichende Isolation der Container gegeneinander und gegenüber dem Host. Aber: Container lassen sich ohne zusätzliche Hilfsmittel bei weitem nicht so gut vom Host isolieren wie etwa virtuelle Maschinen unter KVM/qemu; resultierende Sicherheitsthemen werde ich in kommenden Blog-Beiträgen immer mal wieder aufgreifen. Ich zitiere einen der LXC-Vorkämpfer aus einem frühen Artikel (https://www.berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/):

"Repeat after me “LXC is not yet secure. If I want real security I will use KVM”.

Das gilt mit Einschränkungen wohl auch heute noch; wer den professionellen Einsatz von LXC-Containern erwägt, muss sich mit SE-Linux- oder Apparmor-Profilen sowie ggf. Kernel-Capabilities auseinandersetzen. Ferner empfehle ich, einen Einsatz von LXC-Containern unter KVM-VMs in Betracht zu ziehen, wobei letztere dafür mit virtio-Treibern beschleunigt werden müssen.

Unterschiede zwischen nativen lxc-Tools und libvirt-lxc

Will man mit virt-manager und LXC-Containern arbeiten, begibt man sich auf ein nicht unumstrittenes Gleis. Es gibt nämlich zwei nicht kompatible Toolsets zum Aufsetzen und Verwalten von LXC-Containern: lxc und libvirt-xlc. "lxc" ist das native Toolset und besteht aus einer Reihe sehr flexibel einsetzbaren CLI-Kommandos. "lxc" liegt in den Version 1.1 bzw. 2.0 unter vielen aktuellen Linux-Distributionen vor (Leap 42.2 =>LXC V1.1, Debian Stretch => LXC V2.0). Container werden unter "lxc" über (vorgefertigte) "Configuration Files" definiert.

Libvirt greift dagegen auf XML-Files zur Definition von Containern zurück - also genau wie bei KVM/qemu-VMs. Libvirt nutzt für das LXC-Setup ferner direkte Schnittstellen zum Kernel und rankt darum eigene, unabhängige Tools, die mit den nativen LXC-Tools wenig gemein haben. Man kann native lxc-Kommandos meines Wissens deshalb auch nicht zur Verwaltung der Container verwenden, die mit libvirt-lxc erzeugt wurden. Dafür kann man nach der Einrichtung von libvirt-LXC-Containern aber auf das grafische "virt-manager"-Interface zum Starten, Stoppen und Manipulieren dieser Container zurückgreifen. Auf der Kommandozeile kann alternativ das "virsh"-Kommando mit lxc-bezogenen Optionen eingesetzt werden.

Beide Toolsets nehmen es einem ab, sich um die Konfiguration von cgroups (Ressourcenmanagement) und namespaces (Abschottung) im Detail und händisch kümmern zu müssen. Sie tun dies aber auf unterschiedliche Weise - und stellen zugehörige Informationen keineswegs in kompatibler Weise bereit. In diesem Artikel nutze ich die "libvirt-lxc"-Tools. Nicht zuletzt, weil ich selbst von KVM her komme. Aber - ich sage es vorweg:

Die libvirt-lxc-Tools lassen sich aus meiner Sicht nicht wirklich bruchfrei nutzen.

Der eine oder andere Nutzer wird daher mit wachsender Erfahrung zu den nativen Tools wechseln. Im Internet sind zudem sehr viel mehr Informationen zur Verwaltung von LXC-Containern mit den nativen Tools verfügbar als für die "libvirt-lxc"-Tools. Interessant ist ein LXC-Container-Setup mit libvirt/virt-manager aber allemal.

Ziel: LXC-Betriebssystem-Container

Unter "virt-manager" werden 2 LXC-Container-Typen unterschieden:

  • LXC Distribution Container für eine Umgebung mit einer Root-Filesystem-Struktur für eine Distribution. Solche Container eigenen sich m.E. als Ersatz für KVM/qemu-VMs.
  • LXC Application Container für einzelne Anwendungen. Ein solcher Container bietet nur eine temporäre, isolierte Umgebung für einzelnen Anwendungen - und wird mit dem Schließen der Anwendung auch beendet. Solche Container sind eher mit Docker-Containern vergleichbar.

App-Containern fehlen bei ohne eigene Zusatzmaßnahmen wesentliche Elemente eines für die jeweilige Applikation funktionierenden Filesystems. Das ist ohne vorgefertigte Schablonen Bastelarbeit. Man muss sich je nach Applikation u.a. um Anteile von /etc, /sys, /proc/, /dev, /dev/shm und relevante Bibliotheks-Bereiche wie des Filesystems kümmern. Siehe die Links unten.

Das verführt dazu, am Anfang seiner Lernkurve einen "Betriebssystem-Container" zu erstellen. Für das Filesystem kann man dann nämlich eine Basisimplementation der jeweiligen Distribution heranziehen. Für Debian ist hier "debootstrap" zu nennen.

Bzgl. der praktischen Anlage notwendiger Verzeichnisinhalte erleichtern einem unter dem RPM-basierten Opensuse hingegen sog. Paket-Patterns das Leben. Für ein minimalistisch aufgesetztes Filesystem-Setup greift man hier auf das sog. "base"-Pattern zurück.

Opensuses Script für den Root-Filesystem-Unterbau

Bzgl. der Installation des "base"-Patterns für Container hat die OpenSuSE-Mannschaft es sich in letzter Zeit allerdings etwas zu einfach gemacht: Die aktuelle Doku verweist nämlich auf ein Skript "/usr/bin/virt-create-rootfs".

Diese Script läuft ohne Zusatzwissen und ohne Modifikationen unter Leap 42.2/42.3 aber ins Leere. In Blick in in den Code zeigt: Standardmäßig wird nur Opensuse 13.1 unterstützt; die zugehörigen Repositories, die bemüht werden, sind aber längst obsolet. Ich zeige nachfolgend relevante Ausschnitte aus dem Script:

#!/bin/sh
set -e
....
....
function print_help
{
cat << EOF
virt-create-rootfs --root /path/to/rootfs [ARGS]

Create a new root file system to use for distribution containers.

ARGUMENTS

    -h, --help          print this help and exit
    -r, --root          path where to create the root FS
    -d, --distro        distribution to install
    -a, --arch          target architecture
    -u, --url           URL of the registration server
    -c, --regcode       registration code for the product
    -p, --root-pass     the root password to set in the root FS
    --dry-run           don't actually run it
EOF
}

ARCH=$(uname -i)
ROOT=
DISTRO=
URL=
REG_CODE=
ROOT_PASS=
DRY_RUN=
.....
.....
function call_zypper
{
    $RUN zypper --root "$ROOT" $*
}

function install_sle
{
    PRODUCT="$1"
    VERSION="$2"

    case "$VERSION" in
        12.0)
            # Transform into zypper internal version scheme
            VERSION="12"
            ;;
        *)
            fail "Unhandled SLE version: $VERSION"
            ;;
    esac
....
....

}

case "$DISTRO" in
    SLED-*)
        install_sle "SLED" "${DISTRO:5}"
        ;;
    SLED-* | SLES-*)
        install_sle "SLES" "${DISTRO:5}"
        ;;

    openSUSE-*)
        VERSION=${DISTRO:9}
        case "$VERSION" in
            13.1)
                REPO="http://download.opensuse.org/distribution/13.1/repo/oss/"
                UPDATE_REPO="http://download.opensuse.org/update/13.1/"
                ;;
            *)
                fail "Unhandled openSUSE version: $VERSION"
                ;;
        esac
        call_zypper ar "$REPO" "openSUSE"
        call_zypper ar "$UPDATE_REPO" "openSUSE udpate"
        call_zypper in --no-recommends -t pattern base
        ;;
esac

if test "$DRY_RUN" != "yes"; then
    echo "pts/0" >> "$ROOT/etc/securetty"
    chroot "$ROOT" /usr/bin/passwd
fi

 
Man muss das betreffende Skript also anpassen oder die notwendigen Schritte manuell durchführen.

Modifikation des Scripts

Lässt man mal den Zugriff auf SLES oder SLED-Repositories außer Acht, so leistet das Script im Grunde nur Folgendes:

  • Ein Verzeichnis des Hosts als künftiges root-Verzeichnis des Containers aus einem Übergabeparameter auslesen.
  • Das grundlegende "oss"-Repository sowie das zugeh. Update-Repository für eine Distribution festlegen.
  • "zypper" in der Form "zypper --root PATH_TO_CONTAINER_ROOT in --no-recommends -t pattern" aufrufen.
  • Das root-Password für den chroot-Bereich ändern.

Entscheidend ist im Script-Ablauf die "--root" Option von zypper; die sorgt dafür, dass die Verzeichnisse/Files unterhalb des definierten chroot-Verzeichnisses (PATH_TO_CONTAINER_ROOT) gemäß des definierten Paket-Patterns gefüllt werden. Wir ergänzen das Script deshalb versuchsweise in der Abfrage für die Distribution und ändern die Statements in den Zeilen 205 - 207 ab:

....
.....
case "$DISTRO" in
    SLED-*)
        install_sle "SLED" "${DISTRO:5}"
        ;;
    SLED-* | SLES-*)
        install_sle "SLES" "${DISTRO:5}"
        ;;

    openSUSE-*)
        VERSION=${DISTRO:9}
        case "$VERSION" in
            13.1)
                REPO="http://download.opensuse.org/distribution/13.1/repo/oss/"
                UPDATE_REPO="http://download.opensuse.org/update/13.1/"
                ;;
            42.2)
                REPO="http://download.opensuse.org/distribution/leap/42.2/repo/oss/"
                UPDATE_REPO="http://download.opensuse.org/update/leap/42.2/"
                ;;
            *)
                fail "Unhandled openSUSE version: $VERSION"
                ;;
        esac
        echo "HERE0"
        call_zypper ar "$REPO" "openSUSE"
        echo "HERE1"
        call_zypper ar "$UPDATE_REPO" "openSUSE-udpate"
        echo "HERE2"
        call_zypper in --no-recommends -t pattern enhanced_base
        call_zypper in --no-recommends -t pattern  file_server
        #call_zypper in --no-recommends -t pattern base
        #call_zypper in --no-recommends -t pattern "patterns-openSUSE-enhanced_base"
        ;;
esac

 
Um wenigstens ein paar "Convenience"-Pakte zusätzlich zu erhalten, habe ich das "enhanced_base"-Pattern gewählt.

Anlegen des Filesystems

Für meinen Test nutze ich ein LVM-Volume auf einem SSD-Array; das Volume wird dabei auf das Verzeichnis "/kvm/" gemountet. Das Filesystem meines Containers soll unter "/kvm/lxc2/ zu liegen kommen. Also Verzeichnis angelegt und dann unser umgeschriebenes Script starten:

        
mytux:~ # virt-create-rootfs -r /kvm/lxc2/ -d openSUSE-42.2 
Adding repository 'Leap-42.2-Oss' .......................................................[done]
Repository 'Leap-42.2-Oss' successfully added

URI         : http://download.opensuse.org/distribution/leap/42.2/repo/oss/
Enabled     : Yes                                                          
GPG Check   : Yes                                                          
Autorefresh : No                                                           
Priority    : 99 (default priority)                                        

Repository priorities are without effect. All enabled repositories share the same priority.
Adding repository 'Leap-42.2-Update' ....................................................[done]
Repository 'Leap-42.2-Update' successfully added

URI         : http://download.opensuse.org/update/leap/42.2/oss/
Enabled     : Yes                                               
GPG Check   : Yes                                               
Autorefresh : No                                                
Priority    : 99 (default priority)                             

Repository priorities are without effect. All enabled repositories share the same priority.

New repository or package signing key received:

  Repository:       Leap-42.2-Oss                                       
  Key Name:         openSUSE Project Signing Key <opensuse@opensuse.org>
  Key Fingerprint:  22C07BA5 34178CD0 2EFE22AA B88B2FD4 3DBDC284        
  Key Created:      Mon May  5 10:37:40 2014                            
  Key Expires:      Thu May  2 10:37:40 2024                            
  Rpm Name:         gpg-pubkey-3dbdc284-53674dd4                        


Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a
Building repository 'Leap-42.2-Oss' cache ...............................................[done]
Building repository 'Leap-42.2-Update' cache ............................................[done]
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 163 NEW packages are going to be installed:
  aaa_base bash binutils coreutils cpio cracklib cracklib-dict-full dbus-1 dbus-1-x11
  device-mapper diffutils dirmngr dracut elfutils expat file file-magic filesystem fillup
  findutils fipscheck gawk gio-branding-openSUSE glib2-tools glibc gpg2 grep gzip hardlink
  hwinfo info insserv-compat kbd kbd-legacy klogd kmod kmod-compat krb5 libX11-6 libX11-data
  libXau6 libacl1 libadns1 libaio1 libapparmor1 libasm1 libassuan0 libattr1 libaudit1 libblkid1
  libbz2-1 libcap-ng0 libcap2 libcom_err2 libcrack2 libcryptsetup4 libcurl4 libdbus-1-3 libdw1
  libedit0 libelf0 libelf1 libexpat1 libfdisk1 libffi4 libfipscheck1 libgcc_s1 libgcrypt20
  libgio-2_0-0 libglib-2_0-0 libgmodule-2_0-0 libgmp10 libgobject-2_0-0 libgpg-error0 libidn11
  libkeyutils1 libkmod2 libksba8 libldap-2_4-2 liblua5_1 liblzma5 libmagic1 libmount1
  libmozjs-17_0 libncurses5 libncurses6 libnl-config libnl3-200 libopenssl1_0_0 libpcre1
  libpolkit0 libpopt0 libprocps3 libpth20 libqrencode3 libreadline6 libsasl2-3 libseccomp2
  libselinux1 libsemanage1 libsepol1 libsmartcols1 libssh2-1 libstdc++6 libsystemd0
  libtirpc-netconfig libtirpc3 libudev1 libusb-0_1-4 libusb-1_0-0 libustr-1_0-1 libutempter0
  libuuid1 libverto1 libwicked-0-6 libwrap0 libx86emu1 libxcb1 libxml2-2 libz1 libzio1
  mozilla-nspr ncurses-utils netcfg openSUSE-build-key openSUSE-release openSUSE-release-ftp
  openssh openssl pam pam-config patterns-openSUSE-base patterns-openSUSE-enhanced_base
  perl-base permissions pigz pinentry pkg-config polkit polkit-default-privs procps rpcbind rpm
  sed shadow shared-mime-info suse-module-tools sysconfig sysconfig-netconfig systemd
  systemd-presets-branding-openSUSE systemd-sysvinit sysvinit-tools terminfo-base time udev
  update-alternatives util-linux util-linux-systemd which wicked wicked-service xz

The following 2 NEW patterns are going to be installed:
  base enhanced_base

The following NEW product is going to be installed:
  openSUSE

163 new packages to install.
Overall download size: 48.1 MiB. Already cached: 0 B. After the operation, additional 178.0 MiB
will be used.
Continue? [y/n/...? shows all options] (y): y
....
....
New password: 
Retype new password: 
passwd: password updated successfully

 
Die Installation nimmt kaum Zeit in Anspruch. Danach liegt ein ziemlich umfassendes chroot-Filesystem vor, für das wir auch ein root-Passwort definiert haben:

mytux:~ # la /kvm/lxc2
total 84
drwxr-xr-x 21 root root 4096 Sep 25 18:27 .
drwxr-xr-x  6 root root 4096 Sep 25 18:17 ..
drwxr-xr-x  2 root root 4096 Sep 25 18:28 bin
drwxr-xr-x  2 root root 4096 Oct  7  2016 boot
drwxr-xr-x  2 root root 4096 Sep 25 18:28 dev
drwxr-xr-x 56 root root 4096 Sep 25 18:29 etc
drwxr-xr-x  2 root root 4096 Oct  7  2016 home
drwxr-xr-x  8 root root 4096 Sep 25 18:28 lib
drwxr-xr-x  5 root root 4096 Sep 25 18:28 lib64
drwxr-xr-x  2 root root 4096 Oct  7  2016 mnt
drwxr-xr-x  2 root root 4096 Oct  7  2016 opt
dr-xr-xr-x  2 root root 4096 Oct  7  2016 proc
drwx------  4 root root 4096 Sep 25 18:28 root
drwxr-xr-x  7 root root 4096 Sep 25 18:28 run
drwxr-xr-x  2 root root 4096 Sep 25 18:28 sbin
drwxr-xr-x  2 root root 4096 Oct  7  2016 selinux
drwxr-xr-x  4 root root 4096 Sep 25 18:27 srv
dr-xr-xr-x  2 root root 4096 Oct  7  2016 sys
drwxrwxrwt  7 root root 4096 Sep 25 18:28 tmp
drwxr-xr-x 13 root root 4096 Sep 25 18:27 usr
drwxr-xr-x 12 root root 4096 Sep 25 18:27 var
mytux:~ # 

 

Definition des LXC-Containers mit virt-manager

Wir starten nun virt-manager. Zunächst muss mal LXC auf unserem Host laufen - und wir brauchen eine Verbindung zum lokalen Socket. Dazu bemüht man den Menüpunkt "File >> Add Connection":

Wir drücken dann auf den Button "Connect". Nun legen wir unseren Container an über "File >> New Virtual Machine".

Der Button "Forward" führt zu einem Dialog-Window, in dem wir direkt unser Verzeichnis für das Root-FS eintippen (wir befassen uns nicht mit Storage-Verwaltung).

Wieder "Forward" klicken; wir werden nun aufgefordert, RAM-Größe und die Anzahl der zu verwendenden CPUs festzulegen:

Schließlich geben wir dem Container noch einen Namen:

Die Netzwerk-Konfiguration unterlassen wir im Moment. Der Grund hierfür ist, dass wir ohne Installation weiterer Pakete im Container mit einer Netzwerkverbindung eh' nicht viel anfangen können. Ich komme darauf aber im nächsten Blog-Beitrag zurück. Wir starten die Container-Installation - und uns wird fast umgehend eine Shell angeboten :

Zum Einloggen geben wir das für den chroot-Bereich definierte Passwort ein. So weit, so gut. Ein wenig Herumspielen zeigt sehr schnell: Die Installation ist wirklich recht minimal.

Ausblick

Im nächsten Blog-Beitrag

LXC-Betriebssystem-Container mittels virt-manager unter Opensuse Leap 42.2 - II

ergänze ich zunächst einige nützliche Pakete aus den Opensuse-Repositories. Dann zeige ich, wie man zu einer funktionierenden Netzwerk-Karte in Form eines veth-Devices kommt.

Links

Unterschiede LXC, LXD, Docker
https://unix.stackexchange.com/questions/254956/what-is-the-difference-between-docker-lxd-and-lxc
https://bobcares.com/blog/lxc-vs-docker/
http://www.zdnet.com/article/ubuntu-lxd-not-a-docker-replacement-a-docker-enhancement/

KDE, Plasma 5, sporadisch 100% CPU-Verbrauch und/oder kein Input in Terminalfenster – Workaround

Offenbar geistert in KDE/Plasma5 ein alter Bug herum, der mit animierten Icons im Systemabschnitt der Kontroll-Leiste zu tun zu haben scheint. Über die Ursachen wird spekuliert; in einigen Artikeln zu dem Thema wird OpenGL-Treibern die Schuld gegeben. In anderen einem intrinsischen Bug in der Zusammenarbeit mit Qt. Egal. Die zugrunde liegenden Bugs haben nach meiner Erfahrung mehrere Auswirkungen:

  1. Ab und zu schießt die Belastung auf mindestens einem CPU-Core auf 100% und verbleibt dort.
  2. Keyboard-Eingaben in Terminal-Fenster oder andere bereits offene Input-Felder werden nach einer Arbeitspause ignoriert.
  3. Bei einem Übergang in einen Screen-Saver-Zustand oder gar StandBy-Modus geht ggf. die Verbindung zur Maus oder zum Keyboard verloren.

Das Auftreten jedes der Fehler ist recht sporadisch. Wenn Fehler 1 und 2 passieren und man noch irgendein neues Terminalfenster starten kann, hilft die Eingabe von

myself@mytux:~> killall plasmashell 
myself@mytux:~> kstart plasmashell --shut-up 

um die Probleme für die aktuelle (!) Plasma-Sitzung zu beseitigen.

Es kann gut sein, dass die Ursachen für die beschriebenen Probleme unterschiedlich sind, aber seit dem Anwenden eines bestimmten Workarounds sind gleich alle 3 Probleme nicht mehr aufgetreten. Der Workaround ist nicht auf meinem Mist gewachsen; er ist hier zu finden:

https://www.linuxquestions.org/questions/linuxquestions-org-member-success-stories-23/plasmashell-high-cpu-load-fix-plasma-5-9x-kde-4175606972/

Dort wird kurz und knapp beschrieben, wie man die Animationen für "Notification Icons" beendet:

Open file /usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationIcon.qml
Search for line "running: visible" in "PlasmaComponents.BusyIndicator" section and change it in "running: false".

Siehe auch den letzten Kommentar unter:
https://forum.kde.org/viewtopic.php?f=309&t=136964

Das beenden der Animation hat zwar Informationsnachteile; aber mir ist das lieber als die oben beschriebenen Probleme. Ich lege diesen Workaround in diesem Sinne deshalb jenen Lesern ans Herz, die von selbigen Problemen geplagt werden.

Links
https://askubuntu.com/questions/846781/why-is-plasmashell-using-100-cpu
https://bugs.kde.org/show_bug.cgi?id=356479

https://bugs.kde.org/show_bug.cgi?id=311799
https://github.com/psi-im/psi/issues/249
https://devtalk.nvidia.com/default/topic/995017/linux/high-cpu-usage-of-x-and-kwin-on-opensuse-leap-42-2/
https://bugs.kde.org/show_bug.cgi?id=376966
https://bbs.archlinux.org/viewtopic.php?id=216797
https://ubuntuforums.org/showthread.php?t=2339471
https://bbs.archlinux.org/viewtopic.php?id=218348
https://www.lifewire.com/kubuntu-p2-2202573

Opensuse Leap 42.2, Android, KDE, Dolphin – Dateitransfer mit MTP – Probleme und mögliche Ursachen

Vor einiger Zeit habe ich auf einigen Geräten ein Upgrade auf Leap 42.2 vorgenommen. Das lief alles ganz OK. Nun wollte ich von einem der betroffenen Laptops Dateien auf ein Smartphone übertragen. Dabei stolperte ich bei Einsatz von "MTP" und dem zugehörigen kio-Slave "kio_mtp" unter KDE in ähnliche Probleme, wie sie unter den folgenden Links beschrieben sind:

http://linux-club.de/forum/viewtopic.php?t=121313
https://forums.opensuse.org/showthread.php/526021-Erneute-Probleme-beim-Zugriff-auf-Android-Smartphone-via-MTP
https://forums.oneplus.net/threads/zugriff-auf-daten-ueber-computer.598702/

Ich weiß nicht, ob meine Problem die gleichen Ursachen hatten, wie bei meinen Leidensgenossen - aber die nachfolgenden Punkte sind jedenfalls der Beachtung wert.

Typischer fehlerhafter Verlauf beim Einsatz von "mtp" unter KDE

Fehler 1: Zugriff auf das erkannte Smartphone führt zu keiner Verzeichnisanzeige unter Dolphin

Man schließt das Smartphone an; es kommt zuerst eine Freigabeaufforderung auf dem Smartphone. Danach öffnet man Dolphin - und dann kommt da erneut eine Warnhinweis, dass man das Smartphone freigeben/entsperren müsse; tatsächlich erscheint am Phone eine neue Aufforderung. Die bestätigt man und schließt danach das Popup in Dolphin. Anschließend lädt und lädt Dolphin den Ordnerinhalt angeblich - es passiert aber weiter nichts und zur Anzeige der Speichermedien des Smartphones und deren Inhalte kommt es nie.

Fehler 2: Dolphin kann aus dem Gerätemanager heraus nicht gestartet werden

Ein weiterer ärgerlicher Punkt war in meinem Fall der, dass unter der Geräteüberwachung zwar Dolphin-Icons als Optionen für "Aktionen" angezeigt wurden; ein Klick darauf führte aber jedesmal zu einer Fehlermeldung, die man wegklicken muss. Dolphin öffnet sich dann aber nicht.

Ein solches Verhalten macht einen wahnsinnig; im besonderen, wenn man unter Zeitdruck steht und man weiß, dass früher alles schon mal funktioniert hat. In meinem Fall halfen mir "kde-connect" und die zugehörige App auf dem Smartphone aus der unmittelbaren Patsche heraus, weil beide Geräte (Laptop, Smartphone) sich zufällig im selben WLAN befanden. In unserer Firma gibt es aber Geräte, die aus Sicherheitsgründen in anderen WLAN-Netzen als die Smartphones hängen. Da hilft KDE-Connect nichts. Nun kann man auf SSH-/FTPS-Verbindungen ausweichen. MTP wäre aber doch so einfach ... warum sollte das unter Leap nicht gehen?

Ein paar Experimente

Ich habe dann in meinem Ärger ein wenig rumexperimentiert. Als erster Schritt zur Analyse hilft in einem solchen Fall oft, das Ganze mal mit einem frisch angelegten User oder als User "root" auszuprobieren; Letzteres, um evtl. Rechteprobleme festzustellen.

In meinem Fall reichte schon der erste Schritt: Mit frisch angelegten UserIDs gab es kein größeres Problem mit MTP und einer USB-Kabelverbindung zu unseren verschiedenen Smartphones (LG 2, Samsung Note, Samsung 6). Da lief alles wie erwartet: Anschließen des USB-Kabels an die Linux Workstation, Dolphin öffnen, Android Phone wählen, auf dem Phone die angeforderte MTP-Verbindung freigeben, kurz warten, in Dolphin mit F5 die Ansicht aktualisieren und schließlich durch die Datenträger des Smartphones browsen und Dateien zwischen den Geräten hin und her kopieren.

Workaround
Das brachte mich zu einem ersten Workaround, den ich hier aufliste, weil er vielleicht beim einen oder anderen auch helfen mag. Auf die tatsächlichen Ursachen der Fehler in meiner Konfiguration gehe ich weiter unten ein.

Man lösche - soweit vorhanden - die Dateien "~/.config/dolphinrc", "~/.kde4/share/config/dolphinrc" und das Verzeichnis "~/.local/share/dolphin". Danach funktionierte folgender Workaround relativ zuverlässig:

  • Schritt 1: Anschluss des Smartphone per USB-Kabel an das OS Leap 42.2-Gerät.
  • Schritt 2: I.d.R. kommt keine Freigabeaufforderung auf dem Handy - falls doch: bestätigen.
  • Schritt 3: Geräteüberwachung im Systemtray (Systembereich der Kontrollleiste) öffnen.
  • Schritt 4: Optionen für Android-Gerät anzeigen lassen und auf erstes Dolphin-Symbol klicken.
  • Schritt 5: Fehlermeldung wegklicken und ggf. auftauchende Freigabeaufforderung auf dem Handy positiv beantworten.
  • Schritt 6: Erneut Geräteüberwachung öffnen.
  • Schritt 7: Diesmal auf das 2-te Dolphin-Symbol klicken.
  • Schritt 8: Erneut Fehlermeldung wegdrücken und ggf. Freigabeaufforderung auf dem Handy bestätigen.
  • Schritt 9: Dolphin unabhängig auf dem Desktop öffnen => dort das unter "Geräte" angezeigte > Android-Phone anklicken.
  • Schritt 10: Es werden die auf dem Smartphone verfügbaren Speicherbereiche (Standard "Phone" und (SD-) "Card" angezeigt.

Bei mir tauchte entweder bei Schritt 5 oder bei Schritt 6 eine Freigabeaufforderung auf. Nicht aber zweimal. Die oben beschriebene Schrittfolge ist die einzige, die bei mir zuverlässige Ergebnisse vor den weiter unten geschilderten Maßnahmen produzierte. Der Workaround beseitigte jedoch nicht das Problem des Fehlers beim Klick auf die Dolphin-Symbole in der Geräteüberwachung.

Dieser Zustand ist aus meiner Sicht absurd. Offenbar funktioniert die MTP-Verbindung im Prinzip - aber irgendetwas in der initialen Dialogführung zwischen kio_mtp, Dolphin und dem Android-Phone stimmte einfach nicht.

Lösung 1: Amarok's MTP-Modul muss abgeschaltet werden!

Ich stelle auf einigen meienr Geräten entweder Amarok und Clementine beim KDE-Start zur Verfügung. Sowohl auf dem Laptop als auch auf der Workstation waren nach dem Start von KDE Amarok aktiv. (Auf er Arbeitstation übrigens, weil ich mich gerade mal wieder mit Pulseaudiio herunmschlage. Dazu mehr in einem kommenden Beitrag.)

Es hat mich eine Weile gekostet herauszufinden, dass Amarok standardmäßig das Modul "MTP-Sammlung" aktiviert. Nun stammt Amarok aus KDE4-Zeiten. Das Modul ist offenbar nicht mehr mit der aktuellen KDE5-Umgebung kompatibel oder interferiert in unzulässigerweise mit über "udev" festgelegten Reaktionen auf MTP-Ereignisse.

Also unbedingt im Dialog "Amarok >> Einstellungen >> Amarok Einrichten >> Module" das Modul "MTP-Sammlung" deaktivieren !

Dass dieses Modul wirklich Ungutes tut, kann man dadurch ausprobieren, dass man bei aktiver MTP-Verbindung das Modul mal wieder aktiviert! Viel Glück ...

Lösung 2: KDE-Einstellung unter Standardanwendungen überprüfen

Mein zweiter Fehler hatte damit zu tun, dass ich irgendwann mal "PCManFM" als Dateimanager installiert hatte. Der hatte sich dann selbst in den KDE-Einstellungen als primärer Manager für die Dateiverwaltung hinterlegt. Das funktioniert aber nicht mit der KDE-Geräteüberwachung. Also unter
"systemsettings5 >> Anwendungen >> Standardanwendungen >> Dateiverwaltung" Dolphin als Standard-Dateimanager festlegen.

Schließe ich nun eines unseres Android Smartphones an die Linux-Geräte an, auf denen das erlaubt ist, so funktioniert MTP wieder schnell und flüssig - egal ob an einem USB2.0 oder 3.0-Anschluss.

Fazit

Plugins oder Module von Applikationen, die MTP-Ereignisse erkennen und auf die dahinter liegenden Geräte zugreifen wollen, kommen als potentielle Ursachen von Problemen mit MTP-Verbindungen unter KDE und Dolphin in Frage. Unter Opensuse Leap 42.2 gilt das auf jeden Fall für das MTP-Modul von Amarok. Es ist aber gut vorstellbar, dass auch andere Anwendungen ähnliche Probleme, wie oben diskutiert, zeitigen können. In Frage kommen vor allem Multimedia-Anwendungen. Der KDE-User sollte hierauf eine Auge haben und nach der Installation solcher Anwendungen Tests zu MTP-Verbindungen durchführen.

Viel Spaß weiterhin mit Dateitransfers zu Smartphones - macht das aber bitte nur auf Geräten, auf denen die impliziten Sicherheitsrisiken einer Smartphone-Anbindung kontrollierbar sind, und nur für User mit minimalen Rechten ...