Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disk information returns an error on a LUKS-encrypted Void Linux installation #319

Open
ClementTsang opened this issue Feb 24, 2021 · 3 comments

Comments

@ClementTsang
Copy link

ClementTsang commented Feb 24, 2021

It appears that there are use cases where users who are using encrypted drives in Linux will be unable to get some disk statistics.

This can reproduced by trying to run the disk_usage example from the repo, which results in this error message when trying to access some disks:
image

Running with sudo does work, however:

image

For me, I would assume this would work even without sudo. If this is expected behaviour, feel free to close.


Quick disclaimer, I didn't find this bug, it originally caught in this report: ClementTsang/bottom#419

@ClementTsang ClementTsang changed the title heim fails to load disk information on a LUKS-encrypted Void Linux installation Disk information returns an error on a LUKS-encrypted Void Linux installation Feb 24, 2021
@ClementTsang
Copy link
Author

Was doing some more digging, the crash in the example is probably coming from the .usage() line.

@svartalf
Copy link
Member

Hey, @ClementTsang!

Yeah, your bottom patch is what should be done here: it is expected to have PermissionDenied error if process owner does not have enough rights to query information about filesystem, in this case you are hitting EACCES from the statvfs function.

I was assuming that returning Result from the usage() function would be enough, but do you think I should also add more documentation that caller should expect to receive some particular error kinds and handle them gracefully?

@ClementTsang
Copy link
Author

Firstly, yeah, the issue on my side with the original bug report was on me, I handled the errors in a bit of a weird way (abusing the ? syntax) and got bitten by it. Oops.

do you think I should also add more documentation that caller should expect to receive some particular error kinds and handle them gracefully?

Off the top of my head, that sounds pretty helpful. At least personally, I kinda treat the library as a bit of a black box in many cases, so I guess some documentation on what errors the given implementation might return would make for a bit less head-scratching in some cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants