System maintenance

From ArchWiki
Revision as of 09:42, 23 October 2015 by Alad (talk | contribs) (→‎Clean filesystem: grammar)
Jump to navigation Jump to search

zh-cn:System maintenance

Regular system maintenance is necessary for the proper function of Arch over a period of time. Timely maintenance is a practice many users get accustomed to.

Avoid certain pacman commands

Avoid doing partial upgrades, i.e. never run pacman -Sy and instead use pacman -Syu.

Avoid using the --force option with pacman, especially in commands such as pacman -Syu --force involving more than one package. The --force option ignores file conflicts and can even cause file loss when files are relocated between different packages! In a properly maintained system, it should never need to be used.

Do not use pacman -Rdd package. Using the -d flag skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.

Configuration files

Before editing any configuration files, create a backup. This way, you can revert to a working version in case of problems. Editors like vim and emacs can do this automatically, as well as tools like etckeeper which keep /etc in a version control system (VCS).

Periodically clean configuration files

Old configuration files may conflict with newer software versions, or corrupt over time. Remove unneeded configurations periodically, particularly in your home folder and ~/.config. For similar reasons, be careful when sharing home folders between installations.

Remove old files in the $HOME directory to simplify finding configuration and other useful files. Look for the following folders:

  • ~/.config/ -- where apps stores their configuration
  • ~/.cache/ -- cache of some programs may grow in size
  • ~/.local/share/ -- old files may be lying there
Note: These paths are defaults for $XDG_CONFIG_HOME, $XDG_CACHE_HOME and $XDG_DATA_HOME environment variables respectively. Check your configuration if you use different paths.

See XDG Base Directory support for more information.

To keep the home directory clean from temporary files created at the wrong place, it is a good idea to manage a list of unwanted files and remove them regularly, for example with

rmlint can be used to find and optionally remove duplicate files, empty files, recursive empty directories and broken symlinks.

Check for errors

Failed systemd services

Check if any systemd services have entered in a failed state:

$ systemctl --failed

See Systemd#Analyzing the system state for more information.


Look for errors in the log files located at /var/log, as well as high priority errors in the systemd journal:

# journalctl -p 0..3 -xn

See Systemd#Journal for more information.

Upgrading the system

It is recommended to perform full system upgrades regularly, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once.

See Pacman#Upgrading packages for details. To revert upgrades causing instability, see Downgrading packages.

If the system has packages from the AUR, carefully upgrade all of them.

Read before upgrading the system

Before upgrading Arch, always read the latest Arch News to find out if there are any major software or configuration changes with the latest packages. Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.

Act on alerts during an upgrade

When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.

Deal promptly with new configuration files

When pacman is invoked .pacnew, .pacsave, and .pacorig files can be created. Pacman provides notice when this happens and users must deal with these files promptly. Users are referred to the Pacnew and Pacsave files wiki page for detailed instructions.

Also, think about other configuration files you may have copied or created. If a package had an example configuration that you copied to your home directory, check to see if a new one has been created.

Test updates on a non-critical system

If possible, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.

Install the linux-lts package

The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It can be used by those who want a fallback kernel in case a new kernel version causes problems.

To make it available as a boot option, you will need to update the bootloader's configuration file. For Syslinux, you have to edit /boot/syslinux/syslinux.cfg and duplicate the current entries, except using vmlinuz-linux-lts and initramfs-linux-lts.img. For GRUB, the recommended method is to automatically re-generate the configuration file.

Follow NVD/CVE alerts

Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the NVD Download webpage. See also Arch CVE Monitoring Team and CVE-2014.

Warning: Do not be tempted to perform partial updates, as they are not supported by Arch Linux and may cause instability: the whole system should be upgraded when upgrading a component. Also note that infrequent system updates can complicate the update process.

Use the package manager to install software

Pacman does a much better job than you at keeping track of files. If you install things manually you will, sooner or later, forget what you did, where you installed to, install conflicting software, install to the wrong locations, etc.

From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing.

Use proven software packages

Install mature and proven software, while avoiding cutting edge software that is still buggy. Do not deploy newly developed software until it is proven to be reliable. Use software that has a strong and active development community, as well as a high number of competent users.

Avoid any use of the testing repository, or individual packages from testing. These packages are experimental and not suitable for a stable system.

Unless recommended explicitly, do not install any development packages. These are usually found in AUR, occasionally in the community repository, and are packages taken directly from upstream development branches. They usually feature one of the following words appended to the package name: "dev", "devel", "svn", "cvs", "git", "hg", "bzr", or "darcs". In particular, avoid installing development versions of crucial system packages such as the kernel or glibc.

Choose open-source drivers

Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at

Be careful with unofficial packages

Use precaution when using packages from the AUR or an unofficial user repository. Most are supplied by regular users and thus may not have the same standards as those in the official repositories. Be careful with AUR helpers which highly simplify installation of AUR packages. Always check PKGBUILDs for sanity and signs of mistake or malicious code before building and/or installing the package.

To simplify maintenance, limit the amount of unofficial packages used. Make periodic checks on which are in actual use, and remove (or replace with their official counterparts) any others. See pacman/Tips and tricks#Maintenance for useful commands.

Update the mirrorlist

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: Not part of the system cleanup as in other sections. [edit: when this was written, this section was not well separated from tasks in #Clean filesystem] Already recommended at multiple other places. (Discuss in Talk:Pacman#Don.27t_rush_updates)

Update pacman's mirrorlist, as the quality of mirrors can vary over time, and some might go offline or their download rate might degrade.

See mirrors for details.

Clean the filesystem

When looking for files to remove, it is important to find the files that take up the most disk space. Programs that help with this are found in:

Remove orphaned packages

Remove unwanted packages that are orphans to free up wasted disk space.

See Pacman tips#Removing orphaned packages for details.

Remove unused packages

Remove old, unused packages from the system to free up disk space and simplify maintenance.

See Pacman tips#Removing unused packages for details.

Clean the package cache

Remove unwanted .pkg files from /var/cache/pacman/pkg/to free up disk space.

See Pacman#Cleaning the package cache for more information.

Identify files not owned by any package

Remove unwanted files not listed in the pacman database. Various reasons exist why this may occur.

See Pacman tips#Identify files not owned by any package.

Remove broken symlinks

Old, broken symbolic links might be sitting around your system; you should remove them. Examples on achieving this can be found here and here.

To quickly list all the broken symlinks of your system, use:

 # find . -type l -! -exec test -e {} \; -print

Then inspect and remove unnecessary entries from this list.


Backups may be automated with systemd/Timers.


Create backups of important data at regular intervals. Directories to consider are /etc, /home and /var, and, for server installations, also /srv.

See Backup programs for many alternative applications that may better suit your case. See Category:System recovery for other articles of interest.

List of installed packages

Maintain a list of all installed packages, so that if a complete re-installation is inevitable, it is easier to re-create the original environment.

See Pacman tips#Backing up and retrieving a list of installed packages for details.

Pacman database

The following command can be used to back up the local pacman database:

$ tar -cjf pacman_database.tar.bz2 /var/lib/pacman/local

Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R. See also Pacman tips#Backing up Local database with systemd for an alternative method.

The database can be restored by moving the pacman_database.tar.bz2 file into the / directory and executing the following command:

# tar -xjvf pacman_database.tar.bz2
Note: If the pacman database files are corrupted, and there is no backup file available, there exists some hope of rebuilding the pacman database. Consult Pacman tips#Restore pacman's local database.