bootandy/archived-dust
1
0
Fork 0
mirror of https://github.com/bootandy/dust.git synced 2026-06-08 11:29:05 +03:00
Code Issues 21 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #367] Using ^C on FreeBSD can lead to zombie, unkillable dust executable, using 100% CPU #163

New Issue
Closed
opened 2026-06-08 11:25:57 +03:00 by zhus · 11 comments
zhus commented 2026-06-08 11:25:57 +03:00
Owner
Copy Link
Copy Source

Originally created by @axman6 on GitHub (Feb 11, 2024).
Original GitHub issue: https://github.com/bootandy/dust/issues/367

I’ve run into this issue a few times now, where I’ve been running dust in (which I hope is) a pretty normal way, such as:

$ dust / -X /storage

several times I’ve hit ^C to kill it, and ended up with the executable continuing to run, using 100% CPU, and being unable to kill it with kill <PID> or sudo kill -9 <PID>. The only solution I have is to reboot, which is less than ideal for a server. Let me know if there’s anything I can do to help investigate. For reference, this is happening on FreeBSD 14.0 with all updates installed, dust 0.9.0 built and installed with cargo, rustc 1.76.0, and my file systems are all ZFS.

Originally created by @axman6 on GitHub (Feb 11, 2024). Original GitHub issue: https://github.com/bootandy/dust/issues/367 I’ve run into this issue a few times now, where I’ve been running dust in (which I hope is) a pretty normal way, such as: ```shell $ dust / -X /storage ``` several times I’ve hit ^C to kill it, and ended up with the executable continuing to run, using 100% CPU, and being unable to kill it with `kill <PID>` or `sudo kill -9 <PID>`. The only solution I have is to reboot, which is less than ideal for a server. Let me know if there’s anything I can do to help investigate. For reference, this is happening on FreeBSD 14.0 with all updates installed, dust 0.9.0 built and installed with cargo, rustc 1.76.0, and my file systems are all ZFS.
zhus closed this issue 2026-06-08 11:25:57 +03:00
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Feb 11, 2024):

Indexing: / 1504966 files, 71G ... -^B

Does the indexing keep updating ?

I have no idea why killing it does not work, but that sounds like a problem in the scheduler rather than something that I have any control over.

If you run du and cancel it - does the same behaviour occur ?

If you run without the '-X' does the same behaviour occur ?

<!-- gh-comment-id:1937856171 --> @bootandy commented on GitHub (Feb 11, 2024): >Indexing: / 1504966 files, 71G ... -^B Does the indexing keep updating ? I have no idea why killing it does not work, but that sounds like a problem in the scheduler rather than something that I have any control over. If you run du and cancel it - does the same behaviour occur ? If you run without the '-X' does the same behaviour occur ?
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@axman6 commented on GitHub (Feb 12, 2024):

No, the app stops doing anything at all visually, and never terminates (I've had it running for hours before realising it was still going in the past). I haven't seen the problem with du before, and a few tests just now shows du working as expected. I have see the same behaviour without -X too. I can quite reliably lock up dust with ^C (I just tried to run it in lldb to see if I could gget a stack trace, but hitting ^C in it caused it to lock up and I can't access lldb - how fun!)

I will see if I can get some kind of stack trace of what's happening while it's spinning.

<!-- gh-comment-id:1937939195 --> @axman6 commented on GitHub (Feb 12, 2024): No, the app stops doing anything at all visually, and never terminates (I've had it running for hours before realising it was still going in the past). I haven't seen the problem with du before, and a few tests just now shows du working as expected. I have see the same behaviour without -X too. I can quite reliably lock up dust with ^C (I just tried to run it in lldb to see if I could gget a stack trace, but hitting ^C in it caused it to lock up and I can't access lldb - how fun!) I will see if I can get some kind of stack trace of what's happening while it's spinning.
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Feb 22, 2024):

Does running it single threaded make any difference?
export RAYON_NUM_THREADS=1; dust /

<!-- gh-comment-id:1957962165 --> @bootandy commented on GitHub (Feb 22, 2024): Does running it single threaded make any difference? export RAYON_NUM_THREADS=1; dust /
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Mar 15, 2024):

I can quite reliably lock up dust with ^C

I discovered dust doesn't listen for ^C. Fixing now.

<!-- gh-comment-id:1998516085 --> @bootandy commented on GitHub (Mar 15, 2024): > I can quite reliably lock up dust with ^C I discovered dust doesn't listen for ^C. Fixing now.
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Mar 26, 2024):

will go out in next major release

<!-- gh-comment-id:2018965181 --> @bootandy commented on GitHub (Mar 26, 2024): will go out in next major release
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@axman6 commented on GitHub (Mar 26, 2024):

@bootandy Thanks so much, I'll give master a go on my machine and see if it's helped.

<!-- gh-comment-id:2019114760 --> @axman6 commented on GitHub (Mar 26, 2024): @bootandy Thanks so much, I'll give master a go on my machine and see if it's helped.
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@axman6 commented on GitHub (Mar 26, 2024):

Initial very basic testing (dust / -X /storage as above and hitting ^C) looks good so far!

<!-- gh-comment-id:2019122661 --> @axman6 commented on GitHub (Mar 26, 2024): Initial very basic testing (`dust / -X /storage` as above and hitting ^C) looks good so far!
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@axman6 commented on GitHub (Mar 26, 2024):

... it looks like I spoke too soon, my initial test did work, but now hitting ^C causes it to print Aborting and continue to scan:

~ dust / -X /storage
Indexing: / 2222789 files, 8.3T ... |^C
Aborting
Indexing: / 2232934 files, 8.4T ... |^C
Aborting
Indexing: / 2232934 files, 8.4T ... -^C
Aborting
Indexing: / 2232934 files, 8.4T ... \^C
Aborting
Indexing: / 2232934 files, 8.4T ... \^C
Aborting
Indexing: / 2232934 files, 8.4T ... -^C
Aborting
Indexing: / 2232934 files, 8.4T ... -^C
Aborting
Indexing: / 2232934 files, 8.4T ... -^C
Aborting
Indexing: / 2232934 files, 8.4T ... |^C
Aborting
Indexing: / 2232934 files, 8.4T ... /^C
Aborting
Indexing: / 2232934 files, 8.4T ... -^C
Aborting
Indexing: / 2232934 files, 8.4T ... |^C
Aborting
Indexing: / 2232934 files, 8.4T ... /

And using kill -9 on the executable still doesn't work, and it's still using 100% CPU. Can this issue be reopened?

<!-- gh-comment-id:2019127050 --> @axman6 commented on GitHub (Mar 26, 2024): ... it looks like I spoke too soon, my initial test did work, but now hitting ^C causes it to print Aborting and continue to scan: ```shell ~ dust / -X /storage Indexing: / 2222789 files, 8.3T ... |^C Aborting Indexing: / 2232934 files, 8.4T ... |^C Aborting Indexing: / 2232934 files, 8.4T ... -^C Aborting Indexing: / 2232934 files, 8.4T ... \^C Aborting Indexing: / 2232934 files, 8.4T ... \^C Aborting Indexing: / 2232934 files, 8.4T ... -^C Aborting Indexing: / 2232934 files, 8.4T ... -^C Aborting Indexing: / 2232934 files, 8.4T ... -^C Aborting Indexing: / 2232934 files, 8.4T ... |^C Aborting Indexing: / 2232934 files, 8.4T ... /^C Aborting Indexing: / 2232934 files, 8.4T ... -^C Aborting Indexing: / 2232934 files, 8.4T ... |^C Aborting Indexing: / 2232934 files, 8.4T ... / ``` And using kill -9 on the executable still doesn't work, and it's still using 100% CPU. Can this issue be reopened?
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Mar 28, 2024):

It clearly listens to the Ctrl-C because it prints 'Aborting'.

Here's an idea - Can you run in on a folder other than 'storage' and try and ctrl-C it.

I can't cancel the task it if it is in the middle of scanning a really big file. Each thread will need to finish its file before aborting. So if you have a really massive file in storage there's not much I can do.

Assuming the above works, I'd be curious about running it in each of the sub-folders in storage to figure out what the problem directory looks like

<!-- gh-comment-id:2024068525 --> @bootandy commented on GitHub (Mar 28, 2024): It clearly listens to the Ctrl-C because it prints 'Aborting'. Here's an idea - Can you run in on a folder other than 'storage' and try and ctrl-C it. I can't cancel the task it if it is in the middle of scanning a really big file. Each thread will need to finish its file before aborting. So if you have a really massive file in storage there's not much I can do. Assuming the above works, I'd be curious about running it in each of the sub-folders in storage to figure out what the problem directory looks like
zhus commented 2026-06-08 11:25:57 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Jun 5, 2025):

can we close this issue ?

<!-- gh-comment-id:2941512252 --> @bootandy commented on GitHub (Jun 5, 2025): can we close this issue ?
zhus commented 2026-06-08 11:25:58 +03:00
Author
Owner
Copy Link
Copy Source

@bootandy commented on GitHub (Jul 7, 2025):

this logic changed in 1.2.2, might be fixed.

<!-- gh-comment-id:3046331783 --> @bootandy commented on GitHub (Jul 7, 2025): this logic changed in 1.2.2, might be fixed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
 windows help wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zhus (Sergey Zhukov)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bootandy/archived-dust#163
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?