/var/log/sudo-io/ is occupying over than 44GB

[srmfx]

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.

[millert]

The default value for maxseq is 2176782336. The ideal number of logs kept depends a lot on whether you use sudo on a single-user system, in which case a lower limit makes sense, or on an enterprise system where you may wish to keep the logs more or less forever. With the addition of sudo_logsrvd I think it is probably safe to default to a lower limit for maxseq in sudoers. Large sites can send their logs to sudo_logsrvd with a larger maxseq.

[srmfx]

Yes, agreed; i think sudo should at least warn the user about log sizes being as big as 5GB. I was able to backtrack the issue only after months, because I was busy with University. I can see some users not being able to backtrack this issue and that being an actual issue where they would go out and buy a new hard drive.

There were 44GB worth of logs in my /var/log/sudo-io/ that's too much and I was still going out of Disk Space as I kept using sudo in my system; File Compression could also be taken into cosideration to mitigate this problem.

[millert]

Those logs are compressed by default unless sudo wasn't built with zlib support for some reason.

[srmfx]

Those logs are compressed by default unless sudo wasn't built with zlib support for some reason.

Oic, sudo should at least warn the user about log sizes upon sudo usage, because 44GB is just too big. I also updated the thread topic, because the /var/log/sudo-io/ has just been cleaned after one long hour in my system and it freed up to 44GBs.

[toralf]

2176782336

Maybe completely OT but I'm so curious where this 6^12 comes from ?

[millert]

The I/O log sequence ID is stored as a 6-digit base-36 "number" (decimal digits and upper-case letters) with two digits per directory. For example, /var/log/sudo-io/00/01/A9. The maximum for a 6-digit base-36 number in this form is ZZZZZZ or 2176782336.