Kali Linux automatic autoremove policy for orphaned packages in low-traffic deployments

Direct Answers

Inactivity threshold: 14 days of no apt transactions is a pragmatic default. This balances disk savings against accidentally removing packages orphaned during recent maintenance.

Scheduling mechanism: Use a systemd timer, not an apt hook or cron job. A timer integrates with systemd logging, supports randomized delay to avoid thundering-herd runs, and persists across reboots without overlapping executions.

Forensic cache preservation: Set APT::Clean-Installed "false" in /etc/apt/apt.conf.d/99preserve-cache and invoke apt autoclean (removes only obsolete .deb files) instead of apt clean (wipes the entire archive). This keeps downloaded packages in /var/cache/apt/archives/ for offline reinstall or forensic analysis.

Why These Choices

No Built-In Inactivity Trigger

Debian/APT does not track "package inactivity" — apt-autoremove only runs when explicitly invoked. The rolling-release nature of Kali means metapackages like kali-linux-default frequently pull new dependencies, so orphans accumulate faster than on stable releases.

Systemd Timer vs. Alternatives

• Apt hook (/etc/apt/apt.conf.d/99autoremove) runs after every transaction — unsuitable for "low-traffic" policy because it triggers on any package change.
• Cron lacks systemd's locking, structured logging, and RandomizedDelaySec; overlapping runs can corrupt the dpkg lock.
• Systemd timer provides ConditionPathExists=/var/lib/apt/lists/lock to skip during active operations, persistent timestamps, and journalctl audit trail.

Cache vs. Orphaned Packages

/var/cache/apt/archives/ holds downloaded .deb files (installer cache). apt-autoremove removes installed packages marked auto-installed; it does not touch the archive cache. However, a misconfigured apt clean in a cleanup script would wipe forensics. apt autoclean is safe — it only deletes .deb files no longer in any repository.

Implementation Steps

1. Audit first: Run apt autoremove --dry-run and apt-mark showauto | head -20. Confirm no critical tools (e.g., nmap, metasploit-framework) appear.
2. Pin metapackages: apt-mark manual kali-linux-default kali-tools-top10 (adjust to your installed metapackages) so their dependencies are never auto-removed.
3. Preserve archive cache: Create /etc/apt/apt.conf.d/99preserve-cache with:

   APT::Clean-Installed "false";

4. Create service unit /etc/systemd/system/apt-autoremove.service:

   [Unit]
   Description=Remove orphaned packages
   ConditionPathExists=/var/lib/apt/lists/lock
   [Service]
   Type=oneshot
   ExecStart=/usr/bin/apt-get autoremove -y
   ExecStartPost=/usr/bin/apt-get autoclean -y
   

5. Create timer unit /etc/systemd/system/apt-autoremove.timer:

   [Unit]
   Description=Daily autoremove check with 14-day inactivity
   [Timer]
   OnCalendar=*-*-* 03:00:00
   RandomizedDelaySec=1h
   Persistent=true
   [Install]
   WantedBy=timers.target

6. Enable and verify:

   systemctl daemon-reload
   systemctl enable --now apt-autoremove.timer
   systemctl list-timers apt-autoremove.timer
   journalctl -u apt-autoremove.service -n 50

One Diagnostic Detail Needed

What is the typical maintenance window for these instances? If you have a fixed change-freeze period (e.g., weekends only), the timer's OnCalendar should align to that window rather than a daily 03:00 run. This changes the recommendation from "daily with 14-day inactivity" to "run only during the approved window after 14 days of inactivity."