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>
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)?
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.
🐛🧹 ⚠️ 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!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.