Automating Arch Linux Maintenance with Pacman Hooks

The "Did I Remember to..." Problem

Running a rolling-release distribution like Arch Linux often requires manual intervention after specific package updates. Whether it is regenerating the initramfs after a kernel update, updating the GRUB configuration, or reloading a systemd daemon, these tasks are easy to forget. Forgetting a critical post-update step can lead to a system that fails to boot or services that run with outdated configurations.

The solution is not to write a wrapper script around pacman, but to use ALPM hooks (Arch Linux Package Management hooks). Hooks allow you to define declarative triggers that execute scripts automatically before or after a package transaction, ensuring your system state remains consistent without manual checklists.

How Pacman Hooks Function

Hooks are defined in .hook files using an INI-style format. These files are processed by libalpm, the library powering pacman. There are two primary locations for these files:

• /usr/share/libalpm/hooks/: Default hooks provided by installed packages. You should not edit these, as updates will overwrite them.
• /etc/pacman.d/hooks/: User-defined hooks. Files here take precedence over those in the system directory if they share the same filename.

A hook consists of two main sections: the Trigger, which defines when the hook should fire based on the operation (Install, Upgrade, Remove) and the target (a specific package or a file path), and the Action, which defines what to execute and whether it happens before (PreTransaction) or after (PostTransaction) the package change.

Worked Example: Automating Initramfs Regeneration

A common requirement is running mkinitcpio -P whenever the kernel is updated. While some kernels provide this, creating your own hook ensures it happens exactly how you want it across different kernel flavors.

Configuration

Create the following file as root (using sudo) at /etc/pacman.d/hooks/90-mkinitcpio.hook:

[Trigger]
Operation = Upgrade
Type = Package
Target = linux

[Action]
Description = Updating initramfs... 
When = PostTransaction
Exec = /usr/bin/mkinitcpio -P

Implementation Details

• Permissions: The hook file itself does not need to be executable, but the command in the Exec line must be a valid path to an executable.
• Execution Context: Hooks run as the root user.
• Placeholders: In this example, linux is the target package. If you use linux-lts or linux-zen, you must adjust the target or use a glob pattern.

Verification

To verify the hook without waiting for a kernel update, you can force a reinstall of the target package:

sudo pacman -S linux

During the transaction, look for the line: (1/1) Updating initramfs.... If this appears and the command completes, the hook is functioning correctly.

Trade-offs and Critical Limitations

While powerful, hooks introduce risks to system stability if misconfigured:

• Transaction Blocking: A PreTransaction hook that fails can abort the entire package installation if AbortOnFail is set. This can be disruptive during unattended updates.
• Dependency Loops: Avoid creating hooks that trigger the installation of other packages, as this can lead to unpredictable behavior within the pacman lock.
• Path Triggers: You can set Type = Path to trigger a hook whenever any file in a directory (e.g., /usr/lib/modules/) changes. This is more flexible than package triggers but can cause the hook to fire more frequently than intended.

Summary Checklist

When implementing a new hook, follow these safety steps:

1. Define the hook in /etc/pacman.d/hooks/ to avoid being overwritten.
2. Use absolute paths for all commands in the Exec field.
3. Test the hook on a non-critical package first by temporarily changing the Target.
4. Consult man alpm-hooks to verify the syntax for your specific version of pacman.