iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A sudo session count cannot explain why logs occupy nearly 10 GB: sudo may record brief command events, much larger terminal input/output streams, or neither as the files you are measuring. First identify the exact path using disk-usage tools. The title does not establish which file or subsystem grew on the machine in question, so the steps below help locate the cause without guessing.
Why sudo session count does not predict log size
sudo can write command-event records, and it can also be configured to record session input and output. Those are different kinds of data. An event record describes an action; an I/O recording can capture terminal keystrokes, terminal output, standard input, standard output, and standard error. The volume of captured data can vary substantially from one session to another, so the number of sessions is not a byte count. See the sudoers(5) manual.
The large path might instead belong to the systemd journal, an ordinary text log, or Linux Audit. Each has its own writer and retention controls. Do not delete a file just because its name contains “sudo,” and do not vacuum the journal until you have confirmed it is the space consumer.
Find which path is consuming the space
Use your system’s normal disk-usage tools to locate the large directory or file, then inspect its full path and identify the service or subsystem that writes it. The exact command varies by operating system and installed tools; the essential result is the path, not a guess based on the log’s name. A sudo I/O recording directory, journal storage, conventional text log, and audit log should be diagnosed separately.
#1 Best Overall
Before changing retention, note what the records contain, whether active files are included in the size being reported, how rotation works, how many old files are kept, and what audit or incident-response needs apply. The same headline size can call for different remedies depending on those details.
Match the path to the log store
| Possible store | What it contains | How to check or control it |
|---|---|---|
| systemd journal | Journal records from system services and applications | Use journalctl --disk-usage to see active plus archived journal files. Vacuuming affects archived files only. journalctl manual |
| sudo I/O log directory | Optional per-session input/output recordings, distinct from command-event records | Inspect sudoers policy and the configured I/O log directory. The sudo 1.9.14 manual documents the default local directory as /var/log/sudo-io; verify the installed version and policy. sudo 1.9.14 sudoers manual |
| Ordinary text log | Messages from the daemon or program that owns that file | Check whether the file is covered by a logrotate configuration and inspect its rotation schedule, size rules, compression, and retained-file count. logrotate(8) manual |
| Linux Audit log | Linux Audit records written by auditd | Inspect auditd configuration, including max_log_file_action and num_logs, along with the required retention policy. auditd(8) manual |
If the large path is the systemd journal
Run journalctl --disk-usage to view the combined size of active and archived journal files. The total it reports is not the same as the amount a vacuum operation can immediately remove: --vacuum-size removes the oldest archived journal files until the archived portion is below the requested size. Active files are not removed by vacuuming.
If you need the current active journal file to become eligible for cleanup, rotation may be needed before vacuuming. Choose any size or retention change with the records you still need for diagnosis and audit in mind; reducing storage without checking retention can remove useful history.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →If the large path is sudo’s I/O log directory
Check the active sudoers policy for I/O logging defaults or command tags that enable input or output capture. In the versioned sudo 1.9.14 manual, local I/O recordings default to /var/log/sudo-io and sudo log lines can include unique session IDs marked TSID=. Your installed version or policy may differ, so confirm both before applying configuration advice.
The maxseq setting is documented as a way to cap the I/O log sequence and reuse existing logs. Treat that as a retention decision, not a harmless space-saving toggle: reused or discarded recordings may matter to audit obligations or incident response. Traditional log-rotation tools manage configured ordinary files; they do not directly manage sudo’s per-session I/O directory structure.
Input recording also has a security cost. The sudoers manual warns: “User input may contain sensitive information such as passwords (even when they are not echoed to the screen), which will be stored in the log file unencrypted.” Do not enable broad input capture just to improve accounting. If it is already enabled, consider who can read the recordings and how long policy requires them to be retained.
Rank #4
If the large path is an ordinary text log
Identify the daemon or program writing the file, then find the logrotate rule that includes it. logrotate can rotate logs on a schedule or by size, compress old files, and remove files beyond a configured retention count, but those controls apply only to logs covered by its configuration. Check the relevant stanza and confirm its timer or cron job actually runs before changing the rule.
If the large path is an audit log
Linux Audit records are written to disk by auditd. Its configuration supports size-based rotation by default, and settings such as max_log_file_action and num_logs influence rotation and retention. Confirm that auditd owns the path and consult the applicable retention requirements before reducing records; deleting audit history can undermine investigations or compliance.
Best Value
Choose a fix only after identifying the writer
Once the path and owner are clear, adjust the control for that log store rather than applying a generic “sudo log” cleanup. For the journal, consider journal rotation and archived-file vacuuming. For sudo I/O recordings, review the policy enabling capture and the maxseq behavior. For ordinary text logs, correct the matching logrotate rule or its execution schedule. For audit records, use auditd’s rotation and retention settings in line with required recordkeeping.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
