Linux: Gnome-Desktop (und Verwandte) und seine Schwächen

[Der Martin]

Hallo miteinander,

meine bevorzugte Linux-Distro verwendet den MATE-Desktop, ein Fork von Gnome2. Dadurch treffen viele Probleme, Bugs und Designfehler von Gnome auch auf MATE zu.

Einer davon ist GVFS (Gnome Virtual File System). Das ist, soweit ich es verstanden habe, das Subsystem, das Gnome in die Lage versetzt, andere als das root-Filesystem im Dateimanager anzuzeigen. Eine gute Idee, könnte man meinen.

Ein Dienst, der damit zusammenhängt, sorgt aber immer wieder für Ärger. Eigentlich soll gvfsd-metadata, wie der Name schon andeutet, Metadaten über alle Filesysteme cachen und so den Zugriff beschleunigen.
Fakt ist aber, dass die gespeicherten Daten dieses Dienstes gelegentlich mal korrupt sind, was dazu führt, dass ein CPU-Kern minutenlang zu 100% ausgelastet ist. Fakt ist auch, dass das Caching so aggressiv geschieht, dass der Gnome-Dateimanager Nautilus (oder Caja in MATE) manchmal noch stunden- oder tagelang Dateien anzeigt, die gar nicht mehr existieren (oder umgekehrt Dateien nicht anzeigt, die neu dazugekommen sind). Oder dass der Dateimanager mehrere Sekunden lang einen alten Stand anzeigt, wenn man in ein anderes Verzeichnis wechselt, bis er schließlich merkt: Hoppla, da hat sich seit dem letzten Mal etwas geändert. In der Zeit zeigt er auch in der Statuszeile noch den freien Speicherplatz, wie er zum Zeitpunkt der letzten Anzeige dieses Verzeichnisses aktuell war. Da fragt man sich doch, warum die Entwickler einen solchen Dienst, so gut er auch gemeint ist, nicht erstmal aus dem Verkehr ziehen, bis er reif ist.

Kurz: This service sucks.

Nachdem ich mich vor ein paar Tagen mal wieder darüber geärgert habe, hab ich im Internet einen Hinweis gefunden, dass man diesen Dienst auch schmerzfrei deaktivieren kann. Das habe ich gestern auch getan. Seither beobachte ich argwöhnisch, ob sich dadurch irgendwelche unerwünschten Nebenwirkungen ergeben. Bisher habe ich keine gefunden.
Aber dafür reagiert der Dateimanager jetzt ohne nennenswerte Verzögerung und zeigt auch sofort aktuelle Informationen.

Wer von euch benutzt sonst noch eine Linux-Distro mit Gnome oder einem Nachfahren? Und wer hat schon ähnliche Erfahrungen gemacht oder kann noch mit zusätzlichen Informationen aufwarten? Everything is welcome.

Live long and pros healthy,
 Martin

[Raketenfaustus]

Oh ja. gvfs.

Nachdem ich mich vor ein paar Tagen mal wieder darüber geärgert habe, hab ich im Internet einen Hinweis gefunden, dass man diesen Dienst auch schmerzfrei deaktivieren kann. Das habe ich gestern auch getan. Seither beobachte ich argwöhnisch, ob sich dadurch irgendwelche unerwünschten Nebenwirkungen ergeben. Bisher habe ich keine gefunden.

Das ist normal. Gnome-Programme laufen auch ohne gvfs.

Wer von euch benutzt sonst noch eine Linux-Distro mit Gnome oder einem Nachfahren?

Habe Gnome, KDE, und „Ach!“, auch Unity probiert.

Und wer hat schon ähnliche Erfahrungen gemacht oder kann noch mit zusätzlichen Informationen aufwarten?

Kann zusammen mit dem einst für unverzichtbar gehaltenem gigolo weg. Einzige "Nebenwirkung": Ich mounte meine entfernten Dateisysteme so manuell wie direkt mit sshfs - statt wie früher mit gigolo. Insoweit verändert sich das Öffnen von entfernten Ressourcen durch Gnome-Programme. Das erschien mit Gnome einfacher, war aber verwirrend, weil nur native Gnome-Programme, die Nautilus-libs zum Öffnen nutzten, das konnten.

Auf modernen Betriebssystemen ist zudem systemd-udev oder meinetwegen eudev aktiv und verpetzt unbenutzte oder neu angeschlossene Geräte an Dateimanager, die dann mit fuse & Co. mounten können.

[Der Martin]

Moin,

Oh ja. gvfs.

diese an sich aussagefreie Äußerung spricht Bände. ;-)

Seither beobachte ich argwöhnisch, ob sich dadurch irgendwelche unerwünschten Nebenwirkungen ergeben. Bisher habe ich keine gefunden.

Das ist normal. Gnome-Programme laufen auch ohne gvfs.

Dass dieser besagte Dienst nicht essentiell ist, habe ich schon verstanden. Die Frage ist, ob durch dessen Fehlen irgendwo ein Komfort-Feature wegfällt. Bis jetzt habe ich nicht den Eindruck.

Kann zusammen mit dem einst für unverzichtbar gehaltenem gigolo weg.

Den habe ich auf allen Systemen, wo er nach der Basis-Installation da war, sofort entsorgt.

Auf modernen Betriebssystemen ist zudem systemd-udev oder meinetwegen eudev aktiv und verpetzt unbenutzte oder neu angeschlossene Geräte an Dateimanager, die dann mit fuse & Co. mounten können.

Und damit wären z.B. USB-Datenträger genauso einfach und komfortabel zu benutzen wie mit GVFS? Oder spielt das in dem Fall gar nicht mit?
Das habe ich nämlich seit dem Deaktivieren noch nicht wieder ausprobiert.

Live long and pros healthy,
 Martin

[Raketenfaustus]

Und damit wären z.B. USB-Datenträger genauso einfach und komfortabel zu benutzen wie mit GVFS?

Nein, leider nicht.

Das habe ich nämlich seit dem Deaktivieren noch nicht wieder ausprobiert.

Ich aber. Wenn ich gvfsd und Geschwister brutal deinstalliere und stoppe(!), dann werden frisch eingestöpselte USB-Geräte mit Dateisystemen (Sticks, Platten) nicht mehr automatisch gemounted, Thunar (der XFCE4-Dateimanger) bietet diese auch nicht mehr an. Es fehlt ein Glied in der Verpetz-Kette.

Nach der Wiederinstallation ergibt sich folgendes Bild:

1. Originalzustand:

root@trainer:/etc/systemd# ps ax | grep gvfs
 4763 ?        Ssl    0:00 /usr/lib/gvfs/gvfsd
 4768 ?        Sl     0:00 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
 4825 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
 4840 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
 4844 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-goa-volume-monitor
 4848 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
 4853 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-mtp-volume-monitor
 5163 pts/1    S+     0:00 grep --color=auto gvfs

2. Der Dienst läuft (PID 4763). Killen von gvfsd, Kontrolle:

root@trainer:/etc/systemd# kill 4763
root@trainer:/etc/systemd# ps ax | grep gvfs
 4825 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
 4840 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
 4844 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-goa-volume-monitor
 4848 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
 4853 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-mtp-volume-monitor
 5212 pts/1    S+     0:00 grep --color=auto gvfs

gvfsd ist nicht mehr aktiv.

3. Anstecken eines USB-Sticks, Kontrolle:

root@trainer:/etc/systemd# ps ax | grep gvfs
 4825 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
 4840 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
 4844 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-goa-volume-monitor
 4848 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-afc-volume-monitor
 4853 ?        Ssl    0:00 /usr/lib/gvfs/gvfs-mtp-volume-monitor
 5229 ?        Ssl    0:00 /usr/lib/gvfs/gvfsd
 5234 ?        Sl     0:00 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
 5277 pts/1    S+     0:00 grep --color=auto gvfs

und schon lebt er wieder. (jetzt PID 5229)

Fazit: gvfsd muss man nicht haben, will man aber, dass USB-Sticks und Platten (wahrscheinlich CD/DVD, wohl auch BlueRay automatisch erkannt und gemounted werden, dann braucht man ihn.

Bezüglich des

Auf modernen Betriebssystemen ist zudem systemd-udev oder meinetwegen eudev aktiv und verpetzt unbenutzte oder neu angeschlossene Geräte an Dateimanager, die dann mit fuse & Co. mounten können.

habe ich mich also ziemlich heftig geirrt. Man muss das Zeug von Hand mounten.

Oder spielt das in dem Fall gar nicht mit?

Leider ist er auch bei mir (Ubuntu 18.04 mit XFCE4) in der Kette und wird spätestens dann gestartet, wenn er vorhanden und benötigt wird.

Ausblick auf Ubuntu 20.04 (erst Minimal/Server, dann Paket „xubuntu-Desktop“ installiert). Da sieht es genau so aus:

seminar@ubuntu:~$ ps ax | grep gvfs
   1595 ?        Ssl    0:00 /usr/libexec/gvfsd
   1600 ?        Sl     0:00 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
   1831 ?        Ssl    0:00 /usr/libexec/gvfs-udisks2-volume-monitor
   1839 ?        Ssl    0:00 /usr/libexec/gvfs-goa-volume-monitor
   1894 ?        Ssl    0:00 /usr/libexec/gvfs-gphoto2-volume-monitor
   1914 ?        Ssl    0:00 /usr/libexec/gvfs-afc-volume-monitor
   1923 ?        Ssl    0:00 /usr/libexec/gvfs-mtp-volume-monitor
   1938 ?        Sl     0:00 /usr/libexec/gvfsd-trash --spawner :1.13 /org/gtk/gvfs/exec_spaw/0
   1951 ?        Ssl    0:00 /usr/libexec/gvfsd-metadata
   2001 pts/0    S+     0:00 grep --color=auto gvfs

Wie hattest Du eigentlich gvfs deaktiviert? Als Dienst ist weder gvfsd noch gvfs (wohl aber fuse) registriert?

[Raketenfaustus]

Warte mal ein wenig. Ich habe gerde gesehen, dass Du nicht allgemein gvfs, sondern speziell gvfs-metadata meinst.

Ich muss (sicherheitshalber) mal durch einen reboot verifizieren, was nach dessen Deaktivierung mit

systemctl --user mask gvfs-metadata.service
systemctl --user unmask gvfs-metadata.service

los ist.

[Der Martin]

Hallo,

Warte mal ein wenig. Ich habe gerde gesehen, dass Du nicht allgemein gvfs, sondern speziell gvfs-metadata meinst.

ja, stimmt. Steht auch ausdrücklich so in meinem Originalpost. Sogar mit Link zu askubuntu.com, wo ich den Tipp gefunden hatte. Ob ich GVFS komplett lahmlegen kann/darf, habe ich zwar auch schon ganz vorsichtig überlegt, aber das sollte ich dann vielleicht lieber lassen.

Live long and pros healthy,
 Martin

[Raketenfaustus]

Leider ist mit systemd nicht mehr alles so einfach und durchsichtig wie beim alten init.d:

Ich habe versucht, gvfs-metadata auf folgende weise zu deaktivieren:

systemctl --user mask gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

danach stand er zwar stille (denied), aber nach einer Neuanmeldung war er wieder „alive“...

also:

systemctl --user umask gvfs-metadata.service
systemctl --user disable gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

Auch hier: nach einer Neuanmeldung war er wieder quicklebendig... (jeweils überprüft mit systemctl --user status gvfs-metadata.service)

● gvfs-metadata.service - Virtual filesystem metadata service
   Loaded: loaded (/usr/lib/systemd/user/gvfs-metadata.service; static; vendor pre
   Active: active (running) since Mon 2020-04-20 12:35:59 CEST; 13s ago
 Main PID: 4031 (gvfsd-metadata)
   CGroup: /user.slice/user-1000.slice/[e-mail]/gvfs-metadata.service
           └─4031 /usr/lib/gvfs/gvfsd-metadata

Ihn mit

pkill gvfsd-metadata
rm -rf .local/share/gvfs-metadata

zu beschießen sorgt auch dafür, dass er zwar strirbt, aber beim nächsten Einstöpeln eines USB-Sticks wieder erweckt wird:

● gvfs-metadata.service - Virtual filesystem metadata service
   Loaded: loaded (/usr/lib/systemd/user/gvfs-metadata.service; static; vendor preset: enabled)
   Active: active (running) since Mon 2020-04-20 12:47:45 CEST; 1min 37s ago
 Main PID: 4606 (gvfsd-metadata)
   CGroup: /user.slice/user-1000.slice/[e-mail]/gvfs-metadata.service
           └─4606 /usr/lib/gvfs/gvfsd-metadata

Hm. Demnach ist Dein Probem mit der hohen CPU-Nutzung möglicherweise nicht dauerhaft, wohl aber akut zu beheben…

pkill gvfsd-metadata;
rm -rf "${HOME}/.local/share/gvfs-metadata";

… es sei denn, Du willst gvfs komplett deinstallieren und nimmst den Komfort-verlust in Kauf.

[Der Martin]

Hallo,

Leider ist mit systemd nicht mehr alles so einfach und durchsichtig wie beim alten init.d:

ach was? Ich habe mich schon oft gefragt, was denn am guten alten Sys-V-Init so schlecht war, dass man es ablösen wollte.

Ich habe versucht, gvfs-metadata auf folgende weise zu deaktivieren:

systemctl --user mask gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

Genau das hatte ich auch getan.

danach stand er zwar stille (denied), aber nach einer Neuanmeldung war er wieder „alive“...

Oh. Wie unanständig.

systemctl --user umask gvfs-metadata.service
systemctl --user disable gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

Auch hier: nach einer Neuanmeldung war er wieder quicklebendig...

So 'ne Art Phoenix ...

pkill gvfsd-metadata
rm -rf .local/share/gvfs-metadata

zu beschießen

... ist eine Kur, die gegen gelegentlich auftretende akute Probleme oft empfohlen wird.

sorgt auch dafür, dass er zwar strirbt, aber beim nächsten Einstöpeln eines USB-Sticks wieder erweckt wird:

Da hilft wohl nur noch ein Holzpflock oder ein silberner Dolch. Und reichlich Knoblauch. ;-)

Hm. Demnach ist Dein Probem mit der hohen CPU-Nutzung möglicherweise nicht dauerhaft, wohl aber akut zu beheben…

Das CPU-Problem hatte ich schon lange nicht mehr.

Mich stört hauptsächlich, dass der Dateimanager Caja seinem (manchmal falschen) Cache mehr vertraut als dem tatsächlichen Filesystem und manchmal hartnäckig Gespenster sieht, z.B. temporäre Dateien, die schon längst wieder gelöscht sind, und der Schnarchzapfen hat's bloß nicht gemerkt.
Und dass er beim Verzeichniswechsel manchmal sekundenlang seinen Cache durchwühlt, bis er überhaupt was anzeigt.

Und diese beiden Effekte habe ich mit dem Deaktivieren des metadata-Dienstes eliminiert.

… es sei denn, Du willst gvfs komplett deinstallieren und nimmst den Komfort-verlust in Kauf.

Oder ich schreib mir

systemctl --user mask gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

in mein Anmeldescript.

Live long and pros healthy,
 Martin

[Raktenantiquar]

Leider ist mit systemd nicht mehr alles so einfach und durchsichtig wie beim alten init.d:

ach was? Ich habe mich schon oft gefragt, was denn am guten alten Sys-V-Init so schlecht war, dass man es ablösen wollte.

init konnte die Dienste nur einen nach dem anderen starten. Mit 1-Prozessor-Systemen war das ok, aber heutzutage ist es schon nützlich (zur Vermeidung von unnötig langen Downtimes), wenn mehrere Dienste parallel gestartet werden können. Es sind aber noch ein paar Kleinigkeiten mehr… wie eben Dienste im user-space:

--user

Talk to the service manager of the calling user, rather than theservice manager of the system.

Dafür ist systemd eben anders und „nicht ganz so trivial“.

Aber wenn selbst so ein „alter Sack“ wie ich es bin damit letztendlich doch klar kommt dürfen sich die Jüngeren auch anstrengen. Die kleine Träne steht aber mir als „altem Sack“, der schließlich auch mit einem Wählscheibentelefon (Kinder: ohne Bildschirm!) aufgewachsen ist, auch zu.

[Der Martin]

Hallo nochmal,

systemctl --user mask gvfs-metadata.service
systemctl --user stop gvfs-metadata.service

das beseitigt den Störenfried wirksam, wie wir schon festgestellt haben.
Und wie ich eben festgestellt habe, wirkt sich das nicht auf das praktische Auto-Mounting von USB-Datenträgern aus.

Und der Dienst bleibt auch deaktiviert und wird nicht etwa beim Anstöpseln eines USB-Datenträgers wieder gestartet. Ab- und Neuanmelden habe ich noch nicht probiert, aber da hast du ja schon festgestellt, dann er dann wieder da ist.

Aber dann habe ich jetzt eine Lösung, mit der ich sehr gut leben kann.

Live long and pros healthy,
 Martin

[gvfs-metadata]

Ja. Wenns denn so zu Deiner Zufriedenheit läuft ist doch alles gut. Wo hast Du es notiert? In $HOME/.profile?

[Der Martin]

Hallo,

Ja. Wenns denn so zu Deiner Zufriedenheit läuft ist doch alles gut. Wo hast Du es notiert? In $HOME/.profile?

habe ich noch nicht, aber genau da wollte ich das reinsetzen.

Live long and pros healthy,
 Martin