Tower rebooted itself; can any logs tell me why?

English Install/Boot/Login
#1

Hello

My TW 20170928 shocked me by rebooting itself a couple of hours ago. I had a few pgms open [browser, Thunderbird, TaskCoach, 2 Dolphin windows, Kate, Clementine] & was not actually actively using the Tower at the time [an important phone call had come in several minutes before, which was taking my attention]. I was however still standing at my pc, so i saw it occur… although due to the length of my inactivity the screen had blanked out at least 10’ before the reboot. There was no power-cut that did this. All i knew was that the blank screen sort of flashed, then the bios drive-unlock password box appeared on-screen [only occurs during a boot or reboot]. I was able to get back into my desktop ok, & all seemed normal… except there’s nothing normal about a pc deciding to reboot itself, & causing me to lose stuff i’d been working on when the phone call came in & distracted me.

I wanted to know what made this occur. I launched KSystemLog, but to my annoyance its “oldest” entry was later than the reboot… making it entirely useless. How can i make this log span multiple days or even weeks, not just the measly & inadequate number of lines it gives me… & on that note, why does it ignore my setting for max line numbers?

https://paste.opensuse.org/images/35187367.png

Thanks.

#2

You can retrieve the system log from any prior boot, for example the following retrieves the last boot (before current session). You can also specify earlier boots by decrementing the “-1”

journalctl -b -1

View the last entries in the log. (maybe tail? Or maybe there is an additional journalctl flag)

TSU

#3

Cool, thanks.

However, sadly it tells me nothing useful, i think.


gooeygirl@linux-Tower:~> **sudo journalctl -b -1**
[sudo] password for root: 
-- Logs begin at Tue 2017-08-22 21:09:18 AEST, end at Fri 2017-10-06 18:32:58 AEDT. --
Oct 01 13:22:39 linux-Tower kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27
Oct 01 13:22:39 linux-Tower kernel: random: get_random_bytes called from start_kernel+0x2a/0x42c with crng_init=0
Oct 01 13:22:39 linux-Tower kernel: Linux version 4.13.3-1-default (geeko@buildhost) (gcc version 7.2.1 20170901 [gcc-7-branch revision 251580] (SUSE Linux)) #1 
Oct 01 13:22:39 linux-Tower kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.13.3-1-default root=UUID=f3e11c85-7f1a-4e9e-8585-5b6a61e4ea8c resume=/dev/disk/by-uu
Oct 01 13:22:39 linux-Tower kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'




# I cut out all these, as irrelevant to current problem.




Oct 06 11:54:54 linux-Tower dbus[1438]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Oct 06 11:54:54 linux-Tower dbus[1438]: [system] Successfully activated service 'org.opensuse.Snapper'
Oct 06 11:57:11 linux-Tower dbus[1438]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper)
Oct 06 11:57:11 linux-Tower dbus[1438]: [system] Successfully activated service 'org.opensuse.Snapper'
Oct 06 11:57:14 linux-Tower su[15178]: pam_unix(su:session): session closed for user root
Oct 06 12:21:35 linux-Tower su[17898]: (to root) gooeygirl on pts/4
Oct 06 12:21:35 linux-Tower su[17898]: pam_systemd(su:session): Cannot create session: Already running in a session
Oct 06 12:21:35 linux-Tower su[17898]: pam_unix(su:session): session opened for user root by (uid=1000)
Oct 06 12:21:35 linux-Tower su[17898]: pam_unix(su:session): session closed for user root
Oct 06 12:21:35 linux-Tower su[17903]: (to root) gooeygirl on pts/4
Oct 06 12:21:35 linux-Tower su[17903]: pam_systemd(su:session): Cannot create session: Already running in a session
Oct 06 12:21:35 linux-Tower su[17903]: pam_unix(su:session): session opened for user root by (uid=1000)
Oct 06 12:21:35 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'skanlite' sets config #1
Oct 06 12:21:35 linux-Tower kernel: usb 3-5: usbfs: process 17909 (skanlite) did not claim interface 1 before use
Oct 06 12:21:47 linux-Tower su[17903]: pam_unix(su:session): session closed for user root
Oct 06 12:22:53 linux-Tower smartd[1429]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 73 to 72
Oct 06 12:23:24 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'brscan-skey-0.2' sets config #1
Oct 06 12:23:25 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'scanimage' sets config #1
Oct 06 12:23:25 linux-Tower kernel: usb 3-5: usbfs: process 18009 (scanimage) did not claim interface 1 before use
Oct 06 12:23:26 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'scanimage' sets config #1
Oct 06 12:23:26 linux-Tower kernel: usb 3-5: usbfs: process 18017 (scanimage) did not claim interface 1 before use
Oct 06 12:25:52 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'scanimage' sets config #1
Oct 06 12:25:52 linux-Tower kernel: usb 3-5: usbfs: process 18075 (scanimage) did not claim interface 1 before use
Oct 06 12:25:53 linux-Tower kernel: usb 3-5: usbfs: interface 0 claimed by usblp while 'scanimage' sets config #1
Oct 06 12:25:53 linux-Tower kernel: usb 3-5: usbfs: process 18086 (scanimage) did not claim interface 1 before use
Oct 06 12:32:47 linux-Tower dbus[1438]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
Oct 06 12:32:47 linux-Tower org.kde.powerdevil.backlighthelper[18240]: QDBusArgument: read from a write-only object
Oct 06 12:32:47 linux-Tower org.kde.powerdevil.backlighthelper[18240]: QDBusArgument: read from a write-only object
Oct 06 12:32:47 linux-Tower org.kde.powerdevil.backlighthelper[18240]: QDBusArgument: read from a write-only object
Oct 06 12:32:47 linux-Tower dbus[1438]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Oct 06 12:34:35 linux-Tower dbus[1438]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
Oct 06 12:34:35 linux-Tower org.kde.powerdevil.backlighthelper[18297]: QDBusArgument: read from a write-only object
Oct 06 12:34:35 linux-Tower org.kde.powerdevil.backlighthelper[18297]: QDBusArgument: read from a write-only object
Oct 06 12:34:35 linux-Tower org.kde.powerdevil.backlighthelper[18297]: QDBusArgument: read from a write-only object
Oct 06 12:34:35 linux-Tower dbus[1438]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Oct 06 12:45:41 linux-Tower nm-openvpn[6028]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate b
Oct 06 12:45:41 linux-Tower nm-openvpn[6028]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate b
Oct 06 12:52:53 linux-Tower smartd[1429]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 72 to 73
Oct 06 12:58:44 linux-Tower snapd[1495]: 2017/10/06 12:58:44.681537 snapmgr.go:429: No snaps to auto-refresh found
Oct 06 13:07:23 linux-Tower dbus[1438]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
Oct 06 13:07:23 linux-Tower org.kde.powerdevil.backlighthelper[19388]: QDBusArgument: read from a write-only object
Oct 06 13:07:23 linux-Tower org.kde.powerdevil.backlighthelper[19388]: QDBusArgument: read from a write-only object
Oct 06 13:07:23 linux-Tower org.kde.powerdevil.backlighthelper[19388]: QDBusArgument: read from a write-only object
Oct 06 13:07:23 linux-Tower dbus[1438]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
Oct 06 13:11:08 linux-Tower dbus[1438]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper)
Oct 06 13:11:08 linux-Tower org.kde.powerdevil.backlighthelper[19459]: QDBusArgument: read from a write-only object
Oct 06 13:11:08 linux-Tower org.kde.powerdevil.backlighthelper[19459]: QDBusArgument: read from a write-only object
Oct 06 13:11:08 linux-Tower org.kde.powerdevil.backlighthelper[19459]: QDBusArgument: read from a write-only object
Oct 06 13:11:08 linux-Tower dbus[1438]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper'
lines 4685-4733/4733 (END)

It’s frustrating enough that TW self-rebooted & cost me time & work, but now to [apparently] not be able to diagnose it either… well, sigh.

#4

Reboots can be also caused by power fluctuations. Even extremely short ones

#5

Indeed, and as I mooted in another post, possibly the cause of your file corruption :frowning:

Something to consider, but, they’re rather pricey… although that is relative.

https://www.criticalpowersupplies.co.uk/manufacturers/advance-agt-ait-tvss-mit-constant-voltage-transformer-voltage-stabiliers

If you went down that route I’d highly recommend the Advance CVTs, (long story, which I’ll skip). I guess you could find a local supplier.

#6

Just wondering: do you reboot after upgrading TW?

#7

On Fri 06 Oct 2017 12:06:01 PM CDT, gogalthorp wrote:

Reboots can be also caused by power fluctuations. Even extremely short
ones

Hi
Yes, a loose power cord plug in the power supply, or even the power
supply itself on it’s way out…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.87-18.29-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#8

Thanks all.

OK, so consensus seems to be twas not TW, but more likely my Tower itself, or maybe the local power supply [ie, to my house, not the Tower’s internal PS]. The latter seems least-likely, as my bedside digital clock-radio is usually a very reliable canary-in-coalmine for any external power fluctuation, & it didn’t skip a beat this time. I presume now that the lack of anything relevant in the logs, which i was moaning about, is instead actually a further meta-indication of a root-cause outside TW.

I suppose i’ll need to keep an eye out for future otherwise-unexplained similar incidents, & if so, contemplate my Tower’s internal Power Supply unit’s integrity, as suggested.

Thanks again.

#9

Yes i do. My standard procedure [usually weekly] is

  1. Backup my data to my usb3 sticks
  2. zypper -vvv dup
  3. Agonise over the incomprehensible "…but this requirement cannot be provided
    " warning messages; ask here &/or take a stab in the dark & hope for minimal disasters. 1. Reboot.
#10

There’s been a few more random infrequent self-reboots of Tower since i last posted here. The latest one occurred today [w/ Snapshot 20171111], with Uptime at ~4.5 days, thus preserving the “unblemished” track record of being apparently allergic to achieving uptimes of a week+. Sigh.

This shows the presumed time of the crash/reboot *sudo journalctl --list-boots
*
[sudo] password for root:
-48 1647d698254241a4ba32d58bf5b375dc Tue 2017-08-22 21:09:18 AEST—Tue 2017-08-22 22:53:26 AEST
-47 79f5494ad39d43e7afec94296c8b634d Tue 2017-08-22 22:53:55 AEST—Wed 2017-08-23 01:25:13 AEST
-46 fac352a656584301a643f7dfea4a2039 Wed 2017-08-23 01:25:40 AEST—Wed 2017-08-23 23:57:32 AEST
-45 55bc7fecece342f988b8786c38957e44 Wed 2017-08-23 23:57:57 AEST—Thu 2017-08-24 00:07:13 AEST
-44 c0369fb242994374a77596d7f4e8eae0 Thu 2017-08-24 00:07:38 AEST—Thu 2017-08-24 00:25:06 AEST

<>

-5 7306c287cbcc4005807f0aba8c300736 Fri 2017-11-03 12:59:55 AEDT—Sun 2017-11-05 08:36:16 AEDT
-4 0d384e4d7f5349ac86f5ba30d219ea0c Sun 2017-11-05 08:39:14 AEDT—Fri 2017-11-10 17:09:15 AEDT
-3 ece59ff6c86d458fa06d5e05664ca50c Fri 2017-11-10 17:20:02 AEDT—Fri 2017-11-10 18:31:28 AEDT
-2 53197c33aff8425a93a0e81a08736343 Fri 2017-11-10 18:31:58 AEDT—Mon 2017-11-13 20:13:05 AEDT
-1 10b63c2d7d2e4d16b412e244bc4693e7 Mon 2017-11-13 20:13:49 AEDT—Sat 2017-11-18 13:12:03 AEDT
0 0747cc0189d94d309473b5a808c988ca Sat 2017-11-18 13:21:33 AEDT—Sat 2017-11-18 13:32:03 AEDT
gooeygirl@linux-Tower:~>



I examined the applicable System Log, for clues. Below i have pasted specific excerpts, for which i'd value any interpretative comments pls. Some of these things are clearly unrelated to the reboot problem, & probably deserve separate threads, but for now i'll start out with them altogether here. Other excerpts look scary, containing mention of "*corruption*".

gooeygirl@linux-Tower:~> sudo journalctl -b -1
[sudo] password for root:
– Logs begin at Tue 2017-08-22 21:09:18 AEST, end at Sat 2017-11-18 13:33:49 AEDT. –
Nov 13 20:13:49 linux-Tower kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27

Nov 13 20:55:09 linux-Tower sudo[12569]: pam_unix(sudo:session): session opened for user root by gooeygirl(uid=0)
Nov 13 20:55:09 linux-Tower sudo[12569]: pam_unix(sudo:session): session closed for user root
Nov 13 20:58:23 linux-Tower kernel: SUPR0GipMap: fGetGipCpu=0xb
Nov 13 20:58:23 linux-Tower kernel: vboxdrv: 0000000000000000 VMMR0.r0
Nov 13 20:58:23 linux-Tower kernel: vboxdrv: 0000000000000000 VBoxDDR0.r0
Nov 13 21:01:56 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 000267f5
Nov 13 21:01:56 linux-Tower kernel: Memory corruption detected in low memory
Nov 13 21:01:56 linux-Tower kernel: ------------ cut here ]------------
Nov 13 21:01:56 linux-Tower kernel: WARNING: CPU: 0 PID: 7002 at …/arch/x86/kernel/check.c:141 check_for_bios_corruption+0xa1/0xe0
Nov 13 21:01:56 linux-Tower kernel: Modules linked in: fuse tun af_packet nf_log_ipv6 xt_comment nf_log_ipv4 nf_log_common xt_LOG xt_limit vboxpci(O) vboxnetadp(O) vboxnetflt(
Nov 13 21:01:56 linux-Tower kernel: kvm_intel iTCO_wdt iTCO_vendor_support ppdev r8169 kvm mei_me mii irqbypass pcspkr i2c_i801 lpc_ich mei shpchp fan thermal snd_timer batte
Nov 13 21:01:56 linux-Tower kernel: CPU: 0 PID: 7002 Comm: kworker/0:0 Tainted: G O 4.13.11-1-default #1
Nov 13 21:01:56 linux-Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F7 12/08/2014
Nov 13 21:01:56 linux-Tower kernel: Workqueue: events check_corruption
Nov 13 21:01:56 linux-Tower kernel: task: ffff9db846256000 task.stack: ffffc0c003328000
Nov 13 21:01:56 linux-Tower kernel: RIP: 0010:check_for_bios_corruption+0xa1/0xe0
Nov 13 21:01:56 linux-Tower kernel: RSP: 0018:ffffc0c00332be60 EFLAGS: 00010286
Nov 13 21:01:56 linux-Tower kernel: RAX: 0000000000000028 RBX: ffff9db140010000 RCX: 0000000000000006
Nov 13 21:01:56 linux-Tower kernel: RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff9db95fa0e290
Nov 13 21:01:56 linux-Tower kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000038e
Nov 13 21:01:56 linux-Tower kernel: R10: 00000000000000dd R11: ffffffff962b322d R12: ffffffff96293e10
Nov 13 21:01:56 linux-Tower kernel: R13: 0000000000000001 R14: 0000000080000000 R15: ffffffff80000000
Nov 13 21:01:56 linux-Tower kernel: FS: 0000000000000000(0000) GS:ffff9db95fa00000(0000) knlGS:0000000000000000
Nov 13 21:01:56 linux-Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 13 21:01:56 linux-Tower kernel: CR2: 000005b56d4ee000 CR3: 00000007c4cde000 CR4: 00000000001426f0
Nov 13 21:01:56 linux-Tower kernel: Call Trace:
Nov 13 21:01:56 linux-Tower kernel: check_corruption+0xa/0x40
Nov 13 21:01:56 linux-Tower kernel: process_one_work+0x17c/0x3b0
Nov 13 21:01:56 linux-Tower kernel: worker_thread+0x2e/0x380
Nov 13 21:01:56 linux-Tower kernel: ? process_one_work+0x3b0/0x3b0
Nov 13 21:01:56 linux-Tower kernel: kthread+0x118/0x130
Nov 13 21:01:56 linux-Tower kernel: ? kthread_create_on_node+0x40/0x40
Nov 13 21:01:56 linux-Tower kernel: ? do_group_exit+0x3a/0xa0
Nov 13 21:01:56 linux-Tower kernel: ret_from_fork+0x25/0x30
Nov 13 21:01:56 linux-Tower kernel: Code: 75 0d 5b 5d 41 5c 41 5d 41 5e 41 5f c3 f3 c3 80 3d 8b 5d cc 00 00 75 ea 48 c7 c7 e8 ef a2 95 c6 05 7b 5d cc 00 01 e8 5a 85 07 00 <0f>
Nov 13 21:01:56 linux-Tower kernel: — end trace e008ace8816a5c0b ]—

Nov 14 20:19:31 linux-Tower systemd[1]: Started Network Manager Script Dispatcher Service.
Nov 14 20:19:31 linux-Tower nm-dispatcher[15059]: req:1 ‘dhcp4-change’ [enp2s0]: new request (4 scripts)
Nov 14 20:19:31 linux-Tower nm-dispatcher[15059]: req:1 ‘dhcp4-change’ [enp2s0]: start running ordered scripts…
Nov 14 20:28:52 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 000c5b96
Nov 14 20:34:37 linux-Tower sudo[16475]: gooeygirl : TTY=pts/1 ; PWD=/home/gooeygirl/Desktop ; USER=root ; COMMAND=/usr/bin/journalctl --since 2017-06-01
Nov 14 20:34:37 linux-Tower sudo[16475]: pam_systemd(sudo:session): Cannot create session: Already running in a session
Nov 14 20:34:37 linux-Tower sudo[16475]: pam_unix(sudo:session): session opened for user root by gooeygirl(uid=0)
Nov 14 20:34:39 linux-Tower sudo[16475]: pam_unix(sudo:session): session closed for user root

Nov 17 13:13:57 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 00024cc4

Nov 17 20:18:55 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 00083c01

Nov 18 11:18:18 linux-Tower nm-openvpn[23812]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Nov 18 11:18:25 linux-Tower nm-openvpn[23812]: WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --c
Nov 18 11:18:25 linux-Tower nm-openvpn[23812]: WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

Nov 18 11:54:27 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 00003e6c #Line 4956.

Nov 18 11:54:27 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 00003e6c #Line 5005.

Nov 18 11:54:27 linux-Tower kernel: Corrupted low memory at ffff9db14000e000 (e000 phys) = 00003e6c #Line 5054.

Nov 18 13:12:03 linux-Tower kernel: SFW2-INext-ACC-TCP IN=enp2s0 OUT= MAC=<> SRC=<> DST=<> LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=33094 DF PROTO=TCP SPT=36026 DPT=1739 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B #I don’t know if this line is significant, but it’s the final one.
lines 4913-4961/4961 (END)

#11

Oh, i forgot to also include this in my last post.

The one thing i have noticed as a commonality [symptom, or cause?] prior to each of these random crash-reboots, is that the udisksd process’ memory consumption progressively increases from the previous boot-up. Ordinarily its memory use is very low [eg [u]now, fresh after this recent reboot, it is only 43 MB]. However once the Uptime has reached a few days, this process begins using several hundreds of MB RAM & one time it began using a few GB just before the crash-reboot].

Today when i Resumed the Tower from its overnight Suspend, i noticed almost immediately [via Conky’s “Top 10” RAM users] that udisksd had reached >600 MB… i specifically said to myself under my breath at that time “uh oh, is another crash-reboot about to happen today because this process has once again entered the Top 10?”.

Is this udisksd process some kind of worthy clue for investigation?

History of that process in my posts: https://forums.opensuse.org/showthread.php/527864-udiskd?highlight=udisksd

#12

I’m not sure what is causing it to behave like that for you. Hopefully others can comment further here.

In the meantime, you could kill it

sudo killall udisksd

and the following should be sufficient to get it started again

udisksctl status

Monitor it for memory usage again…

top -p `pgrep -f udisksd`

Maybe a bug report will be required.

#13

Hi
Or is it related to your USB device I/O errors… is you backup automated, maybe it’s getting in a loop?

#14

No, not related at all. Though i made both posts at similar times, they have nothing to do with each other. The USB stick problem has not existed for as long as the [infrequent, irregular] self-reboot problem. Furthermore that stick does not live permanently plugged in, but only is inserted weekly for my weekly data backups to it via BackInTime. All said b/u’s are manually initiated, there is no automated schedule.

#15

…but, but, but… https://forums.opensuse.org/showthread.php/527864-udiskd?p=2843284#post2843284

I would never kill it.

Do i do this only once i see that daemon appear in the “Top 10”, or well before, ie, pre-emptively?

OK, happy to, but not sure yet that i have enough objective data to make a sensible useful b/r.

#16

Well, ordinarily there should be no need to kill it, but in the context of testing it won’t do anything destructive.

Do i do this only once i see that daemon appear in the “Top 10”, or well before, ie, pre-emptively?

It was suggested for test purposes so that you could then establish that the memory footprint resets accordingly. However, like Malcolm has already postulated, it is likely that there is an underlying issue (and the udisksd memory consumption is a symptom of that).

#17

Just in case this is relevant to your situation…
https://sebtombs.com/computing/linux/77-udisksd-stuck-at-100-cpu.html

#18

Thanks. It’s interesting, but i’m unsure that it applies to me. My observations of that daemon entering the Top 10 are for RAM usage, not cpu usage [which always stays pretty low on my TOWER (i emphasised that only in case you might be conflating my unrelated Lappy’s new problem, initiated by max cpu, that i mentioned today in another thread)].

However this is still interesting;

If you leave lots of dolphin windows open (as I usually do) and one of them refers to a disk which has been moved, dolphin remembers something which then causes the udisksd problem. Close all dolphin windows and the problem will go away.

coz i do indeed leave several Dolphin windows active, permanently, & usually with multiple tabs in each. Maybe i should change my habit & routinely close Dolphin as soon as i finish each specific task for which i used it…