/var/log/sudo-io/ is occupying over than 44GB
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 34/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c, linux
- Domain
- backend, operating-systems
Research direction
The report concerns sudo I/O log storage under /var/log/sudo-io/ and the maxseq setting in /etc/sudoers. Read how sudo configures and stores I/O logs, then assess the proposed default sequence limit and the alternative disk usage warning. Done means addressing excessive log growth for users without maxseq, with behavior that can be verified for both existing and future users.
Written by the indexing model from the issue text.
Description
I just checked my Hard Disk a few months ago and couldn't help but notice I was running out of disk for no reason, it took me like those few months in order backtrack to this issue. There are more than 44GB worth of logs on my /var/log/sudo-io/ directory and the issue happens because /etc/sudoers file had not a "Default maxseq=1000" attribute.
In other words, i've been having those logs for like over 10 years, it took me like a few hours to delete it whole.
It would be nice if you guys could fix this issue for both future and current users who do not have "Default maxseq" attribute set in their /etc/sudoers file.
This probably has been eating a lot of HD Disk Space for a lot of unaware linux users.
I'm on archlinux. IMHO, There should be a default threshold to Default maxseq.
--UPDATE:
If that option is not possible, sudo should at least warn the user about log sizes on the disk when it gets as big as 5GB, then the user would be given the option to fix the problem by cleaning /var/log/sudo-io/ logs or to turn off the warning manually in /etc/sudoers file just in case they don't care about files being too big.
- Dominant language
- C
- Stars
- 1.7k
- Forks
- 306
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 24
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sudo-project/sudo
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
sudo-project/sudo#583 ·
Maintainers usually reply within 1 day
-
Signal forwarded to the command is lost when it arrives between fork() and execve() of the commandOpen
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sudo-project/sudo#566 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
sudo-project/sudo#553 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
sudo-project/sudo#552 ·
Maintainers usually reply within 1 day
-
Documentation text overflows container instead of wrappingMay be free again @BittuBarnwal7479 claimed this 131 days ago, and no pull request is open. Open
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
sudo-project/sudo#547 · 1 comment ·
Maintainers usually reply within 1 day
All issues in sudo-project/sudo
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ly05010419/MacNativeGames#1420 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
JustAResearcher/gpu-unlock-ada#124 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
swoole/swoole-cli#1092 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
inflate: total_in uses plain += on c_ulong (32-bit on Windows), panics in debug for streams > 4 GiBOpen
Difficulty 1/5 Under an hour Newbie friendliness 85/100
trifectatechfoundation/zlib-rs#570 · 1 comment ·