Probleme mit dem Prozess "udisksd"

Message
Author
loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#11 Post by loik »

Moin.

PCmanFM finde ich unstrittig.
Der hat lange Zeit zu meinen Lieblingen gehört.
Aber nachdem ihm die einfache Möglichkeit "als Root öffnen" ( oder Admin oder so ... ) abgeschafft wurde, verlor er für mich an Nutzen und geriet in Vergessenheit.
Ja, man konnte sich einen Root-Zugang basteln, aber das hatte mich genervt. Vor allem es auf jedem System wiederholen zu müssen.

Die Qt-Variante, die ich bis jetzt noch gar nicht kannte, ist da ja um einiges besser.
Gefällt mir sehr gut.
Besonders die Filterleiste.
Wirkt auf mich, wie ne Mischung aus PCmanFM und Dolphin.
Nur das die Darstellungsgrösse innerhalb des Fensters nicht einfach Zoom-bar ist, finde ich schlapp.

Und wenn wir schon dabei sind:
Thunar mochte ich noch nie so richtig.
Aber was ich an dem tatsächlich ganz besonders zu schätzen weiß ist die Möglichkeit, das Kontextmenü des Rechtenmausklicks benutzerdefiniert gestalten zu können.
Hoch individuell.
Da kann ihm kein anderer das Wasser reichen. Beeindruckend.


Symlinks:
Die nerven mich immer und sind bei Caja so richtig mistig. Vor allem umständlich zu erstellen.
Wegen zuverlässiger Symlinks benutze ich extra nur dafür xfe.
Dessen Symlinks sind so stabil, dass sie sogar BkUps bzw. Syncronisieren ( und Kopieren ) überleben.

Beispiel:
Ich habe ein ca. 30GB großes Daten-"System".
Also, Meine Dateien und Ordner, in denen ich mir meinen alltäglichen Kram speichere sind ca. 30GB groß.
Ohne Film- oder Audiodateien aber mit schon inkl. 6 GB Fotos.

Innerhalb dieser Datei-Struktur habe ich sehr viele Symlinks angelegt.

Wenn ich von diesem Daten-"System" eine BkUp-Kopie auf eine SD-Karte mache, und diese Karte an einem anderen Linux-Pc einlege, dann funktionieren die Symlinks innerhalb dieser Kopie immer noch.
Ebenso, wenn ich mit FreeFileSync synchronisiere.

Aber eben nur, wenn ich zuvor die Symlinks mit xfe erstellt habe.
Anders erstellte Symlinks werden in so einem BkUp als defekt angezeigt.

Jedenfalls war das noch vor 6 Jahren so.
Ich weiß nicht, ob es da Verbesserungen bei den einzelnen Dateimanagern gab.
Ist dann sogar mir zu aufwendig, das jedes Jahr für jeden Dateimanager zu überprüfen.

Bei Verknüpfungen finde ich es nach wie vor sehr bedauerlich, dass Linux nicht mit den Microsoft-Shortcuts ( .lnk ) umgehen kann.
Fänd ich super, wenn die sowohl lesbar als auch MS-kompatibel erstellbar währen.

An Symlinks ist sehr gut, dass sie NUR Zugang zu dem verlinkten Bereich geben.
Von dort geht es nicht weiter nur zurück, dahin, woher man kam.

Und das finde ich aber auch schlecht an Symlinks.
Das nervt mich oft kolossal.

Das mag ich wiederum an MS-schortcuts sehr, dass man die Wahl hat von dort per Rückwärtspfeil zurückzugelangen oder per Aufwärtspfeil in der Zielumgebung bzw. in dessen Eltern-Ordner zu bleiben.

Symlink ist sicher.
MS-shortcut ist praktisch.

Kann man sich ja vorher überlegen, was die angemessene Link-Variante ist.
Wenn man es denn könnte. :rolleyes:


Und wenn es um Symlinks geht, sind alle Dateimanager bis auf Dolphin, total grotte, wenn es darum geht, vollständig Auskunft zu geben, wo der Symlink denn hinzielt.
Dolphin gibt darüber nicht nur nachvollziehbare Auskunft sondern bietet auch die Möglichkeit "Ziel anzeigen" womit man dann im Eltern-Ordner der des Ziels ( der realen Datei ) landet und von dort aus weiter navigieren kann.
( Leider wird das Ziel mit Thunar geöffnet. Keine Ahnung, wo ich das wie umstellen kann, dass dafür ein anderer Dateimanager genommen wird. z.B. Dolphin selbst )

Damit schafft Dolphin eine Umgangsweise mit Symlinks wie sie MS-shortcuts von Haus aus bieten.
Danke, Dolphin.


So, schön vom Thema abgekommen.
Auf das eigentliche komme ich gleich nochmal zurück.

loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#12 Post by loik »

Hallo, Gosia.

Nein, ich habe dir nix übel genommen.
Ich kann das schon nachvollziehen.
Wenn mich ein Thema nicht von sich aus schon mal interessiert, fällt es mir schwer mich da einzulesen.
Und umso schwerer, wenn es langatmig ist.

Trotzdem schwierig für mich, Informationsgrundlage und Wortmengenbegrenzung zusammenzubringen.
Wenn ich es knapp schreibe, kann ich permanent nachliefern, bis für die Hilfsbereiten ein vollständiges Bild entsteht.
Hält das Publikum aber bei mehr Aufmerksamkeit und am Mitdenken.
Vielleicht sollte ich in Zukunft doch die Salamitaktik versuchen. :p


Das mit mount werde ich in Zukunft mal im Auge behalten.

Aber, bei meinem ersten Test war es so, dass zu dem Zeitpunkt das Laufwerkt "Dummy" mal wieder als "verwaist" durchgekreuzt war und statt dessen alternativ das Laufwerk "Dummy_1" angeboten wurde.

Der Mount-Befehl hat dieses verwaiste Laufwerk erst gar nicht aufgelistet. Nur das "Dummy_1"-Laufwerk.

Code: Select all

sudo mount
ebenso.


Ich versuche es noch mal klar zu stellen:
Laufwerke verschwinden während des laufenden Betriebes NICHT.

Bereits eingebundenen Laufwerke sind die ganze Zeit erreichbar, benutzbar.

Erst wenn ich ein weiteres USB-Laufwerk anstöpsel, merke ich, das was nicht stimmt.
Dieses neue Laufwerk wird vom System "nicht wahrgenommen", nicht angezeigt.
Ich kann es dann eben nicht einhängen, weil nicht vorhanden.

Auf die weitere Nutzung von zuvor eingebundenen USB-Laufwerken hat das keinen Einfluss.

Wenn ich dann versuche, Gnome-Disk-Manager zu öffnen um nachzuschauen, was da los ist, dann startet das Programm nicht. ( es läuft nur Dauerhaft dieser "in Arbeit"-Dreh-Kringel )
Aber es passiert gar nix.

Wenn ich alternativ Gparted starte, wird dort das Laufwerk halt nicht angezeigt.

Erst, wenn ich nun den Prozess udisksd beende, kommt Bewegung in die Sache.
Alle auf meinem Desktop angezeigten Laufwerke verschwinden.
Dann starte ich problemlos gnome-diks und dabei werden alle Laufwerke wieder automatisch eingehängt.
Auch das zuvor nicht erkannte.

Kann sein, dass es nun weitere verwaiste Einträge in der Laufwerksliste der Dateimanager gibt ( Das können wir aber vorerst "ignorieren", ist vermutlich nur eine Begleiterscheinung. )

Manchmal bekomme ich das Problem auch mit, ohne dass ich versuche, ein neues USB-Laufwerk hinzuzufügen.

Nämlich, indem ich Dolphin starte.
Bzw. es versuche.

Weil es gelingt dann nicht.
Das Fenster friert auf halben Start-Weg ein.
Da ist dann nur so n leerer Fensterrahmen.
Lässt sich auch nicht mehr wegmachen.

Wenn ich dann versuche gnome-disks zu starten passiert da ebenfalls wieder nix.

Also Prozess udisks beenden und alles geht wieder.
Gnome-disks lässt sich dann starten ebenso wie Dolphin.


Vorführeffekt halber, passiert nun grad nix beispielhaftes.
Ich schaffe es nicht, das sonst häufig und lästige Problem zu provozieren.

Sonst hätte ich versucht das blockierte gnome-disks über das Terminal zu starten, um euch eine Fehlermeldung zu Posten.

Das werde ich bei Gelegenheit ( die kommt bestimmt ) nachholen.
You do not have the required permissions to view the files attached to this post.

loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#13 Post by loik »

Mmmmhhrregrrrrr

Die Fehlermeldung beim Start über das Terminal sagt natürlich überhaupt nix aus :frown:

Code: Select all

$ gnome-disks

(gnome-disks:5917): GNOME-Disks-ERROR **: 21:27:43.878: Error getting udisks client: Zeitüberschreitung wurde erreicht
Trace/Breakpoint ausgelöst

User avatar
gosia
Posts: 1152
Joined: Sun Apr 28, 2019 3:43 pm

Re: Probleme mit dem Prozess "udisksd"

#14 Post by gosia »

Hallo loik,
loik wrote: Sun Feb 20, 2022 3:31 pm Die Fehlermeldung
könnte damit zusammenhängen, dass udisksd nicht läuft, bzw. abgestürzt ist.
Was sagt denn

Code: Select all

pgrep -fl udisk
viele Grüsse gosia

loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#15 Post by loik »

Hallo, Gosia.

"Erfreulicher" Weise passt es grad.

udisksd ist genau passend "eigefrohren".

der Prozessstatus sieht dabei so aus:
udisksd.png
Die ausgaben zu "deinem" Befehl sehen im "gefrorenen" Zustand so aus:

Code: Select all

$ pgrep -fl udisk
4105 gvfs-udisks2-vo
4109 udisksd
4280 mount.ntfs
11076 mount.ntfs
11080 mount.ntfs
11084 mount.ntfs
11090 mount.ntfs

Code: Select all

$ sudo pgrep -fl udisk
[sudo] Passwort für user-mx-1932: 
4105 gvfs-udisks2-vo
4109 udisksd
4280 mount.ntfs
11076 mount.ntfs
11080 mount.ntfs
11084 mount.ntfs
11090 mount.ntfs
13927 sudo
Im nicht blockiertem Zustand sieht das so aus:

Code: Select all

$ pgrep -fl udisk
4105 gvfs-udisks2-vo
4280 mount.ntfs
11076 mount.ntfs
11080 mount.ntfs
11084 mount.ntfs
11090 mount.ntfs
14373 udisksd

Code: Select all

$ sudo pgrep -fl udisk
4105 gvfs-udisks2-vo
4280 mount.ntfs
11076 mount.ntfs
11080 mount.ntfs
11084 mount.ntfs
11090 mount.ntfs
14373 udisksd
14728 sudo
Das sagt mir alles nix.

Ja, und nach dem Beenden des Prozesses udisksd und dem erneuten Starten von gnome-disks,
sieht dass dann so harmlos aus.
udisksd - normal.png

Als ich gestern Abend den Startversuch von gnome-disk über das Terminal machte, war das wärend einer "Frostblockade" auf einem MX-19.4-64bit xfce, auf einem schwachbrüstigen ATOM-Mini-PC von ASUS.
Da wundert man sich dann nicht über Froststarre bei 96% CPU-Last für den Prozess udiskd.

Aber heute, genau passend, stammen diese Informationen von einem MX-19.4-32bit xfce, auf einem i5-HP. :bagoverhead:

Code: Select all

Snapshot created on: 20210111_2123
System:    Kernel: 4.19.0-18-686-pae i686 bits: 32 compiler: gcc v: 8.3.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.19.0-18-686-pae 
           root=UUID=<filter> ro quiet splash 
           Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm 4.14.0 vt: 7 
           dm: LightDM 1.26.0 Distro: MX-19.4_386 patito feo November 11  2020 
           base: Debian GNU/Linux 10 (buster) 
Machine:   Type: Desktop System: Hewlett-Packard product: HP Compaq Elite 8300 USDT v: N/A 
           serial: <filter> Chassis: type: 3 serial: <filter> 
           Mobo: Hewlett-Packard model: 3398 serial: <filter> BIOS: Hewlett-Packard 
           v: K01 v02.05 date: 05/07/2012 
Battery:   Device-1: hidpp_battery_0 model: Logitech Wireless Touch Keyboard K400 
           serial: <filter> charge: 100% (should be ignored) rechargeable: yes 
           status: Discharging 
CPU:       Info: Quad Core model: Intel Core i5-3470S bits: 64 type: MCP arch: Ivy Bridge 
           family: 6 model-id: 3A (58) stepping: 9 microcode: 21 cache: L2: 6 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 23146 
           Speed: 2381 MHz min/max: 1600/2900 MHz Core speeds (MHz): 1: 2381 2: 2444 3: 2378 
           4: 2661 
           Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled 
           Type: mds mitigation: Clear CPU buffers; SMT disabled 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
           STIBP: disabled, RSB filling 
           Type: srbds status: Vulnerable: No microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics 
           vendor: Hewlett-Packard driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0152 
           class-ID: 0300 
           Display: x11 server: X.Org 1.20.4 compositor: xfwm4 v: 4.14.0 driver: 
           loaded: modesetting unloaded: fbdev,vesa display-ID: :0.0 screens: 1 
           Screen-1: 0 s-res: 3360x1080 s-dpi: 96 s-size: 888x285mm (35.0x11.2") 
           s-diag: 933mm (36.7") 
           Monitor-1: HDMI-1 res: 1920x1080 hz: 60 dpi: 92 size: 531x299mm (20.9x11.8") 
           diag: 609mm (24") 
           Monitor-2: DP-2 res: 1440x900 hz: 60 dpi: 90 size: 408x255mm (16.1x10.0") 
           diag: 481mm (18.9") 
           OpenGL: renderer: Mesa DRI Intel Ivybridge Desktop x86/MMX/SSE2 v: 4.2 Mesa 18.3.6 
           compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard 
           driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1e20 class-ID: 0403 
           Device-2: Logitech type: USB driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-3.2:5 
           chip-ID: 046d:0a19 class-ID: 0300 
           Device-3: Creative SoundBlaster MP3+ type: USB 
           driver: hid-generic,snd-usb-audio,usbhid bus-ID: 3-1.2:4 chip-ID: 041e:3010 
           class-ID: 0300 
           Sound Server-1: ALSA v: k4.19.0-18-686-pae running: yes 
           Sound Server-2: PulseAudio v: 12.2 running: yes 
Network:   Device-1: Intel 82579LM Gigabit Network vendor: Hewlett-Packard driver: e1000e 
           v: 3.2.6-k port: f080 bus-ID: 00:19.0 chip-ID: 8086:1502 class-ID: 0200 
           IF: eth0 state: down mac: <filter> 
           Device-2: Realtek RTL8191SU 802.11n WLAN Adapter type: USB driver: r8712u 
           bus-ID: 1-2:2 chip-ID: 0bda:8172 class-ID: 0000 serial: <filter> 
           IF: wlan0 state: up mac: <filter> 
Drives:    Local Storage: total: 268.29 GiB used: 45.84 GiB (17.1%) 
           ID-1: /dev/sda maj-min: 8:0 vendor: Seagate model: ST9160301AS size: 149.05 GiB 
           block-size: physical: 512 B logical: 512 B speed: 1.5 Gb/s type: HDD rpm: 5400 
           serial: <filter> rev: SDM2 temp: 30 C scheme: MBR 
           SMART Message: Unknown smartctl error. Unable to generate data. 
           ID-2: /dev/sdb maj-min: 8:16 type: USB vendor: Lexar model: 128GB SSD 
           size: 119.24 GiB block-size: physical: 512 B logical: 512 B type: SSD 
           serial: <filter> rev: 0110 scheme: MBR 
           SMART Message: A mandatory SMART command failed. Various possible causes. 
Partition: ID-1: / raw-size: 23.76 GiB size: 23.26 GiB (97.90%) used: 18.91 GiB (81.3%) fs: ext4 
           block-size: 4096 B dev: /dev/sdb6 maj-min: 8:22 
Swap:      Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default) 
           ID-1: swap-1 type: partition size: 3.05 GiB used: 0 KiB (0.0%) priority: -2 
           dev: /dev/sdb8 maj-min: 8:24 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C 
           Fan Speeds (RPM): N/A 
Repos:     Packages: 3055 note: see --pkg apt: 3050 lib: 1569 flatpak: 5 
           Active apt repos in: /etc/apt/sources.list 
           1: deb http://repository.spotify.com/ testing non-free
           Active apt repos in: /etc/apt/sources.list.d/anydesk-stable.list 
           1: deb http://deb.anydesk.com/ all main
           Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 
           1: deb http://deb.debian.org/debian/ buster-updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/debian.list 
           1: deb http://deb.debian.org/debian/ buster main contrib non-free
           2: deb http://deb.debian.org/debian-security/ buster/updates main contrib non-free
           Active apt repos in: /etc/apt/sources.list.d/mx.list 
           1: deb http://nl.mxrepo.com/mx/repo/ buster main non-free
           Active apt repos in: /etc/apt/sources.list.d/opera-beta.list 
           1: deb https://deb.opera.com/opera-beta/ stable non-free #Opera Browser (final releases)
           Active apt repos in: /etc/apt/sources.list.d/spotify.list 
           1: deb http://repository.spotify.com/ stable non-free
           Active apt repos in: /etc/apt/sources.list.d/teamviewer.list 
           1: deb https://linux.teamviewer.com/deb/ stable main
           Active apt repos in: /etc/apt/sources.list.d/various.list 
           1: deb http://deb.opera.com/opera/ stable non-free
           No active apt repos in: /etc/apt/sources.list.d/vivaldi.list 
Info:      Processes: 249 Uptime: 1h 55m wakeups: 7 Memory: 7.72 GiB used: 2.06 GiB (26.6%) 
           Init: SysVinit v: 2.93 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 8.3.0 
           alt: 8 Shell: quick-system-in default: Bash v: 5.0.3 running-in: quick-system-in 
           inxi: 3.3.06 
You do not have the required permissions to view the files attached to this post.

User avatar
gosia
Posts: 1152
Joined: Sun Apr 28, 2019 3:43 pm

Re: Probleme mit dem Prozess "udisksd"

#16 Post by gosia »

Hallo loik,
da sehe ich eigentlich nur, dass meine Annahme, dass udisksd nicht läuft, falsch war. Keine Ahnung, was bei dir schief läuft. Aber ich bleibe dabei, das killen von udisksd kann auf Dauer nicht gut sein. Das ist ungefähr so, als ob Du deinen USB-Stick abziehst, obwohl er noch gemountet ist.
Also, ich bin mangels weiterer Ideen so gut wie raus.

viele Grüsse gosi

loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#17 Post by loik »

Hallo, Gosia.
Danke für den Versuch zu helfen.

Was mich sehr wundert, ist dass der Prozess udisks auf 96% CPU hochgeht, wo er dann eben häufig "einfriert".
Ich verstehe gar nicht, was der Großes leisten muss, dass er auf soviel Prozessorleistung zugreifen muss ?

Wenn dafür jemand eine Theorie oder Idee hätte ....

User avatar
gosia
Posts: 1152
Joined: Sun Apr 28, 2019 3:43 pm

Re: Probleme mit dem Prozess "udisksd"

#18 Post by gosia »

Hallo loik,
ich habe weder eine Theorie und noch weniger eine Idee. Habe mal udisksd eine Zeitlang beobachtet. Schwankt bei mir zwischen 0.0% - 0.5% Auslastung. Keine Ahnung, warum das bei dir so hoch läuft. Irgendwas ist da faul bei dir, aber was???

viele Grüsse gosia

loik
Posts: 2275
Joined: Wed Dec 12, 2018 2:01 pm

Re: Probleme mit dem Prozess "udisksd"

#19 Post by loik »

Moin, Gosia.

Danke, für das Überprüfen.
Und die damit verbundene Bestätigung.
Ich hatte auch erwartet, dass der Prozess grundsätzlich unter 10% laufen müsste.

Es passiert ja, wie schon genannt auf all meinen MX-Systemen von MX 18, über 19 bis 21.
Und auf 32 wie 64bit gleichermaßen.

Nun, kann man natürlich die Augen rollen, wenn man beachtet, dass diese Systeme auch immer wieder Klone von einander sind.
aber von 18 zu 19 habe ich nix geklont und von 32 zu 64 bit auch nix.

Damit dürfte das Klonen nicht die Ursache für die Häufung sein.

Aber, seit 2014 benutze ich einen 128 GB usb-Stick von Terra als Daten und Arbeitsstick.
Ursprünglich auch zusätzlich als Systenstick.
Es befinden sich noch LM13 und LM14 darauf.

Und entweder der Kontroller auf den Stick ist Grund schlecht oder defekt oder, ich habe da eine Seuche drauf.

Denn, es ist schon zu beobachten, das der Stick manchmal noch ewig am Blinken ist, obwohl der Rechner bereits herunter gefahren wurde.
Das hört meist erst dann auf, wenn ich auch den Strom ausschalte.
Der Stick steckte dabei in einer USB-Aktiv-Hub-Leiste.
War also nicht vom Strom des PCs abhängig.

Dieser Stick kommt fast immer zum Einsatz.
Ich habe bisher noch nicht darauf geachtet, ob der udisksd-Hänger auch auftritt, wenn ich diesen Stick gar nicht verwende.

Gibt es ein Tool, mit dem ich den Stick auf technischen Defekt oder Virus überprüfen kann ?

Jedenfalls hatte ich erstmal ein Problem im Zusammenhang mit MX vermute, weil ich unter LinuxMint ( 13, 17, 18 ) keine Probleme mit udisksd und diesen Stick hatte.

User avatar
gosia
Posts: 1152
Joined: Sun Apr 28, 2019 3:43 pm

Re: Probleme mit dem Prozess "udisksd"

#20 Post by gosia »

Hallo loik,
ich würde mal einen Tag lang ohne den Stick und auch ohne den USB-Hub probieren. Ein USB-Stick, der seit ca. acht Jahren ziemlich oft benutzt wird kann schon anfällig sein. Kann sein, muss nicht. Aber wenn es ohne die beiden Teile einen Tag (oder längeren Zeitraum) gut läuft, wäre das ein Hinweis. Ich will MX nicht gänzlich als Verursacher ausschliessen, aber warum gibt es dieses Problem bei mir mir nicht? Bei mir hängt zwar kein USB-Stick aber eine USB-FP dran, was für udisksd auf das gleiche rauskommen sollte.

viele Grüsse gosia

Post Reply

Return to “Deutsches Forum”