Bug 508772

Summary:	kup-daemon crashes and prevents the machine from sleeping
Product:	[Applications] kup	Reporter:	Daniel M <daniel>
Component:	general	Assignee:	Simon Persson <simon.persson>
Status:	RESOLVED WORKSFORME
Severity:	crash
Priority:	NOR
Version First Reported In:	0.10.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Daniel M 2025-08-26 17:27:47 UTC

SUMMARY
On occasion my system will fail to sleep/suspend and it appears it’s related to kup.

I'm a bit new to Linux, so getting a backtrace for kup-daemon is likely a bit over my head, but I figured I'd report this anyway.

STEPS TO REPRODUCE
1. Close the lid of the notebook
2. Notice the computer fails to go to sleep (sometimes)
3. View dmesg and note kup-daemon has crashed

OBSERVED RESULT
kup-daemon crashes and prevent the computer from sleeping.

EXPECTED RESULT
kup-daemon does not crash and the computer sleeps.

SOFTWARE/OS VERSIONS
Operating System: Void 
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.17.0
Qt Version: 6.8.2
Kernel Version: 6.16.0_1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics
Memory: 58.6 GiB of usable RAM
Graphics Processor: AMD Radeon 780M

ADDITIONAL INFORMATION
Is it possible this occurs more often when the computer wakes and then goes back to sleep shortly thereafter.

From dmesg:
Freezing user space processes failed after 20.005 seconds (1 tasks refusing to freeze, wq_busy=0):
[<    0.000162>] task:kup-daemon      state:D stack:0     pid:1643  tgid:1643  ppid:1309   task_flags:0x400000 flags:0x00004006
[<    0.000016>] Call Trace:
[<    0.000007>]  <TASK>
[<    0.000009>]  __schedule+0x52e/0x1580
[<    0.000020>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000012>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000011>]  schedule+0x2a/0xd0
[<    0.000015>]  request_wait_answer+0xce/0x260 [fuse]
[<    0.000023>]  ? __pfx_autoremove_wake_function+0x10/0x10
[<    0.000012>]  __fuse_simple_request+0xd7/0x290 [fuse]
[<    0.000018>]  fuse_dentry_revalidate+0x12e/0x340 [fuse]
[<    0.000018>]  ? __alloc_skb+0x89/0x1a0
[<    0.000023>]  lookup_fast+0xea/0x100
[<    0.000014>]  walk_component+0x1f/0x150
[<    0.000008>]  path_lookupat+0x55/0x180
[<    0.000009>]  filename_lookup+0xf4/0x200
[<    0.000018>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000009>]  vfs_statx+0x80/0x160
[<    0.000013>]  vfs_fstatat+0x6b/0xa0
[<    0.000011>]  __do_sys_newfstatat+0x3b/0x80
[<    0.000018>]  do_syscall_64+0x84/0x2f0
[<    0.000015>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000007>]  ? preempt_count_add+0x4b/0xa0
[<    0.000009>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000007>]  ? fput+0x3f/0x90
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? __sys_sendmsg+0xcd/0xf0
[<    0.000014>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? fpregs_assert_state_consistent+0x32/0x60
[<    0.000009>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? preempt_count_add+0x4b/0xa0
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? fput+0x3f/0x90
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? fpregs_assert_state_consistent+0x32/0x60
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0x1ec/0x2f0
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? fput+0x3f/0x90
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000007>]  ? fpregs_assert_state_consistent+0x32/0x60
[<    0.000006>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000008>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? fpregs_assert_state_consistent+0x32/0x60
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000007>]  ? srso_alias_return_thunk+0x5/0xfbef5
[<    0.000006>]  ? do_syscall_64+0xbc/0x2f0
[<    0.000010>]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[<    0.000008>] RIP: 0033:0x7f070cf0d6aa
[<    0.000007>] RSP: 002b:00007ffcb771e418 EFLAGS: 00000246 ORIG_RAX: 0000000000000106
[<    0.000010>] RAX: ffffffffffffffda RBX: 00005591e2db0a58 RCX: 00007f070cf0d6aa
[<    0.000005>] RDX: 00007ffcb771e460 RSI: 00005591e2dbac90 RDI: 00000000ffffff9c
[<    0.000004>] RBP: 00005591e2dcd250 R08: 0000000000000050 R09: 00007ffcb771e398
[<    0.000005>] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcb771e650
[<    0.000004>] R13: 00007ffcb771e440 R14: 00007ffcb771e750 R15: 00005591e2dcd250
[<    0.000012>]  </TASK>

Comment 1 Simon Persson 2025-09-09 18:04:36 UTC

Thanks for the report!

kup-daemon is watching the filesystem for changes to the destination folder (or it's parent folders) if you have selected a file system path as the backup destination. ISince I see "fuse" mentioned in the dmesg output, I am guessing that you are saving to some filesystem path that is backed by some fuse filesystem? If so, perhaps you can test if the problem goes away when changing where to save backups, to some place locally on your computer (not a fuse filesystem)?

Comment 2 Daniel M 2025-09-09 18:25:22 UTC

I appreciate you chiming in Simon. I can easily say the problem goes away after kup-daemon has crashed as it's no longer running. You mentioned fuse and this is correct in that I have kup backing up over sshfs via an entry in /etc/fstab (there is little reason for me to backup locally as, for me, the main point is being able to recover my data if my SSD or related fails) and I imagine this is directly related. Based on this, do you see a way of resolving this with this configuration? Ideally, I guess, having kup support bup's native SSH functionality would be ideal, but this report is not a feature request.

Comment 3 Bug Janitor Service 2025-09-24 03:47:14 UTC

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Comment 4 Bug Janitor Service 2025-10-09 03:47:05 UTC

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.