DEV Community: Nurlan

How to Find and Clean Up Unowned `pycache` Directories on Arch Linux

Nurlan — Mon, 02 Jun 2025 06:08:02 +0000

When you install or run Python-based tools on Arch Linux — especially from the AUR — you might notice that your system accumulates a lot of __pycache__ directories. These are generated when Python byte-compiles modules, but they aren’t always removed when you uninstall a package.

In this short guide, we’ll walk through how to identify and optionally clean up those __pycache__ directories — specifically the ones not owned by any package — and exclude system paths like Flatpak while we're at it.

Why Does This Happen?

Tools installed via the AUR (like waydroid-scripts-git, for example) might drop files under /opt, /usr/local, or other places. These files (especially .py and __pycache__) might not be tracked by pacman, so even after uninstalling the tool, leftover Python cache directories can remain.

Finding Unowned `pycache` Directories

Here’s a one-liner that will:

Search your system for all __pycache__ directories
Skip the Flatpak directory (/var/lib/flatpak)
Check whether each is owned by any package
Print only the ones that are not owned

find / -type d -name '__pycache__' -not -path '/var/lib/flatpak/*' 2>/dev/null | while read dir; do
  pacman -Qo "$dir" &>/dev/null || echo "Not owned: $dir"
done

Output Example

Not owned: /opt/waydroid-scripts/tools/__pycache__
Not owned: /usr/local/lib/python3.11/site-packages/some_tool/__pycache__

Conclusion

__pycache__ directories aren't dangerous, but they can accumulate and clutter your system — especially in directories that aren’t cleaned by package managers. With a few commands, you can find and clean up these leftovers safely, keeping your system neat and under control.

Have your own cleanup tricks? Share them in the comments!

Fingerprint Not Working After Sleep?

Nurlan — Sat, 10 May 2025 19:05:57 +0000

If you're using fprintd for fingerprint authentication on Linux and encounter this error after waking your system:

Device reported an error during identify: Cannot run while suspended.

…it likely means the fingerprint device fails to recover correctly after suspend or hibernate.

The Quick Fix

You can fix this by restarting the fprintd service automatically after resume. Here's how:

1. Create a systemd service

Create a file at /etc/systemd/system/restart-fprintd-after-suspend.service:

[Unit]
Description=Restart fprintd after suspend
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart fprintd.service

[Install]
WantedBy=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

2. Enable the service

Enable the service running this command:

sudo systemctl enable --now restart-fprintd-after-suspend.service

Now fprintd will restart automatically after suspend or hibernate, and your fingerprint sensor should work reliably again.

Understanding Drop-in Overrides in systemd: When Parameters Accumulate vs Override

Nurlan — Sat, 10 May 2025 11:54:37 +0000

When working with systemd units, you often want to override or tweak an existing unit file without rewriting it entirely. That's where drop-in overrides come in.

But there's a subtle behavior many people miss: not all parameters behave the same way when overridden! Some get completely replaced; others accumulate values.

This article explains this behavior, especially for those dealing with .timer or .service files.

🔍 What are drop-in overrides?

A drop-in override is an additional configuration file placed under /etc/systemd/system/<unit>.d/*.conf that supplements or overrides the main unit definition.

For example:

/etc/systemd/system/pkgfile-update.timer.d/override.conf

Contents:

[Timer]
OnCalendar=weekly

It lets you modify behavior without touching /usr/lib/systemd/system/pkgfile-update.timer.

Another way to do this is to run:

sudo systemctl edit unit --drop-in=drop_in_name

This opens the file /etc/systemd/system/unit.d/drop_in_name.conf in your text editor (creating it if necessary) and automatically reloads the unit when you are done editing. Omitting --drop-in= option will result in systemd using the default file name override.conf.

But here's the catch: `OnCalendar` doesn't override, it adds

If the original timer file contains:

[Timer]
OnCalendar=daily

And your drop-in contains:

[Timer]
OnCalendar=weekly

Then both schedules will be active: daily and weekly.

This is because OnCalendar supports multiple entries; adding a new one doesn't replace the old.

You can verify this with:

systemctl show pkgfile-update.timer | grep OnCalendar

✅ How to truly override `OnCalendar`

To replace existing values, you must explicitly reset the field:

[Timer]
OnCalendar=
OnCalendar=weekly

The first OnCalendar= clears all previous values. The second sets the new one.

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart pkgfile-update.timer

Key takeaway

If you override parameters in systemd drop-ins, be aware:

Some parameters stack up (accumulate) → use an empty assignment to clear.
Others overwrite directly.

This small difference can save hours debugging why your override didn't "take effect".

Happy systemd hacking!