Difference between revisions of "Enhance system stability"

From ArchWiki
Jump to navigation Jump to search
(Always back up config files before editing: the suffix is arbitrary and distinguishing custom backups from .pac* files is really not the point of config backups)
(This is just a lot of talk; no content remaining, redirect)
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:System administration]]
+
#REDIRECT: [[System maintenance]]
[[ar:Enhance system stability]]
 
[[fr:Enhancing Arch Linux Stability]]
 
[[ja:Arch Linux の安定化]]
 
[[pt:Enhance system stability]]
 
[[ru:Enhance system stability]]
 
[[zh-cn:Enhance system stability]]
 
{{Related articles start}}
 
{{Related|System maintenance}}
 
{{Related articles end}}
 
{{Merge|System maintenance|One common place for recommended practices|Talk:System maintenance}}
 
The purpose of this wiki article is to provide tips and best practices on how to make an Arch Linux system as stable as possible. While Arch Developers and Trusted Users work hard to produce high quality packages, given Arch's rolling release system and rapid package turnover, an Arch system may not be suitable for a mission critical, commercial production environment.
 
 
 
However, Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able to enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction.
 
 
 
How stable can Arch Linux really be? There are numerous reports in the Arch forums of skilled system administrators successfully using Arch for production servers. Archlinux.org is one such example. On the desktop, a properly configured and maintained Arch installation can offer excellent stability.
 
 
 
== Maintaining Arch ==
 
 
 
In addition to configuring Arch for stability, there are steps one can take during maintenance which will enhance stability. Paying attention to a few SysAdmin details will help to ensure continued system reliability.
 
 
 
For repetitive tasks that need to be done regularly see [[System maintenance]].
 
 
 
=== Read before upgrading the system ===
 
 
 
Before upgrading Arch, always read the latest [https://www.archlinux.org/news/ 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 {{Pkg|glibc}}) to a new version, look over the appropriate [https://bbs.archlinux.org/ 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 {{ic|.pacnew}}, {{ic|.pacsave}}, and {{ic|.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.
 
 
 
=== Avoid certain pacman commands ===
 
 
 
Avoid doing [[partial upgrades]], i.e. never run {{ic|pacman -Sy}} and instead use {{ic|pacman -Syu}}.
 
 
 
Avoid using the {{ic|--force}} option with pacman, '''especially''' in commands such as {{Ic|pacman -Syu --force}} involving more than one package. The {{ic|--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 {{Ic|pacman -Rdd package}}. Using the {{ic|-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.
 
 
 
=== Use up-to-date mirrors ===
 
 
 
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the [https://www.archlinux.org/mirrors/status/ Mirror Status webpage] to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance.
 
 
 
Also, if it is used, edit the mirror list in {{ic|/etc/pacman.d}} by placing local mirrors, those within your country or region, at the top of the list. Refer to the [[Mirrors#Enabling a specific mirror]] for additional details, including the installation of the [[Mirrors#List by speed|rankmirrors]] script to enable the fastest mirrors. These steps will ensure that the system uses the fastest, most reliable mirrors.
 
 
 
=== Revert package upgrades that cause instability ===
 
 
 
{{Merge|Downgrading packages|particularly the note on IgnorePkg}}
 
 
 
In the event that a particular package upgrade results in system instability, install the last known stable version of the package from the local pacman cache using the following command:
 
 
 
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz
 
 
 
For more detailed information on reverting to older packages, consult the Arch wikipage, [[Downgrading packages]].
 
 
 
Once the package is reverted, temporarily add it to the [[Pacman#Skip package from being upgraded|IgnorePkg section of pacman.conf]], until the difficulty with the updated package is resolved. Consult the Arch wiki and/or webforums for advice, and file a bug report if necessary.
 
 
 
==== Install the linux-lts package ====
 
 
 
The {{Pkg|linux-lts}} package is an alternative Arch kernel package, and is available in the [[Official repositories#core|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 {{ic|/boot/syslinux/syslinux.cfg}} and duplicate the current entries, except using {{ic|vmlinuz-linux-lts}} and {{ic|initramfs-linux-lts.img}}. For [[GRUB]], the recommended method is to automatically [[GRUB#Generate the main configuration file|re-generate the configuration file]].
 
 
 
=== Be careful with unofficial and less tested packages ===
 
 
 
Avoid any use of the testing repository, or individual packages from testing. These packages are experimental and not suitable for a stable system.
 
 
 
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.
 
 
 
==== Avoid development packages ====
 
 
 
To prevent breakage of the system, do not install any development packages, unless recommended explicitly. 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.
 
 
 
If building a custom package using ''makepkg'', be sure that the PKGBUILD follows the [[Arch packaging standards]], including a {{ic|provides}} array. Use [[namcap]] to check the final ''.tar.gz'' or PKGBUILD file.
 
 
 
== Generic best practices ==
 
 
 
=== 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 [[Creating packages|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. For example, [[PulseAudio]]'s early versions could be unreliable. Users interested in maximum stability would use the [[ALSA]] sound system instead. Finally, use software that has a strong and active development community, as well as a high number of competent users.
 
 
 
=== Use recommended configurations ===
 
 
 
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. Always choose the recommended, default configuration when setting up the system. The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.
 
 
 
=== 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 [http://www.linux-drivers.org/ linux-drivers.org].
 
 
 
=== Follow NVD/CVE alerts ===
 
 
 
Subscribe to the Common Vulnerabilities and Exposure Security Alert updates, made available by National Vulnerability Database, and found on the [http://nvd.nist.gov/download.cfm 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.}}
 
 
 
=== 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.
 
 
 
=== Always back up config files before editing ===
 
 
 
{{Accuracy|Many editors do this by default}}
 
 
 
Before editing any configuration file, always back up a known working version of that config file. In the event that changes in the config file cause problems, one can revert to the previous stable config file. Do this from a text editor by first saving the file to a backup copy before making any alterations; or execute the following command:
 
 
 
cp config config~
 
 
 
[[etckeeper]] can help dealing with config files. It keeps the whole {{ic|/etc}} directory in a version control.
 
 
 
==== 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 {{ic|~/.config}}. For similar reasons, be careful when sharing home folders between installations.
 

Latest revision as of 09:24, 23 October 2015

Redirect to: