https://wiki.archlinux.org/api.php?action=feedcontributions&user=Kopfweh&feedformat=atomArchWiki - User contributions [en]2024-03-29T05:03:02ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=374424Unofficial user repositories2015-05-21T12:19:11Z<p>Kopfweh: </p>
<hr />
<div>[[Category:Package management]]<br />
[[ja:非公式ユーザーリポジトリ]]<br />
[[zh-CN:Unofficial user repositories]]<br />
{{Expansion|Please fill in the missing information about repository maintainers.}}<br />
<br />
{{Related articles start}}<br />
{{Related|pacman-key}}<br />
{{Related|Official repositories}}<br />
{{Related articles end}}<br />
<br />
This article lists binary repositories freely created and shared by the community, often providing pre-built versions of PKGBUILDS found in the [[AUR]].<br />
<br />
{{Warning|Neither the official Arch Linux Developers nor the Trusted Users perform tests of any sort to verify the contents of these repositories; it is up to each user to decide whether to trust their maintainers, and take full responsibility for whatever their decision brings.}}<br />
<br />
In order to use these repositories, you will have to add them to {{ic|/etc/pacman.conf}}, as explained in [[pacman#Repositories]]. If a repository is signed, you will have to obtain and locally sign the associated key, as explained in [[Pacman-key#Adding unofficial keys]].<br />
<br />
If you want to create your own custom repository, follow [[pacman tips#Custom local repository]].<br />
<br />
{{Tip|To get a list of all servers listed in this page: {{bc|<nowiki>curl 'https://wiki.archlinux.org/index.php/Unofficial_user_repositories' | grep 'Server = ' | sed "s/\$arch/$(uname -m)/g" | cut -f 3 -d' '</nowiki>}}<br />
<br />
For your convenience you can, for example, open them all in a web browser to inspect the contents of their repositories.<br />
}}<br />
<br />
== Adding your repository to this page ==<br />
<br />
If you have your own repository, please add it to this page, so that all the other users will know where to find your packages. Please keep the following rules when adding new repositories:<br />
<br />
* Keep the lists in alphabetical order.<br />
* Include some information about the maintainer: include at least a (nick)name and some form of contact information (web site, email address, user page on ArchWiki or the forums, etc.).<br />
* If the repository is of the ''signed'' variety, please include a key-id, possibly using it as the anchor for a link to its keyserver; if the key is not on a keyserver, include a link to the key file.<br />
* Include some short description (e.g. the category of packages provided in the repository).<br />
* If there is a page (either on ArchWiki or external) containing more information about the repository, include a link to it.<br />
* If possible, avoid using comments in code blocks. The formatted description is much more readable. Users who want some comments in their {{ic|pacman.conf}} can easily create it on their own.<br />
<br />
== Any ==<br />
<br />
"Any" repositories are architecture-independent. In other words, they can be used on both i686 and x86_64 systems.<br />
<br />
=== Signed ===<br />
<br />
==== bioinformatics-any ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/decryptedepsilon/ decryptedepsilon]<br />
* '''Description:''' A repository containing some python packages and genome browser for Bioinformatics<br />
* '''Key-ID:''' 60442BA4<br />
<br />
{{bc|<nowiki><br />
[bioinformatics-any]<br />
Server = http://decryptedepsilon.bl.ee/repo/any<br />
</nowiki>}}<br />
<br />
==== infinality-bundle-fonts ====<br />
<br />
* '''Maintainer:''' [http://bohoomil.com/ bohoomil]<br />
* '''Description:''' infinality-bundle-fonts repository.<br />
* '''Upstream page:''' [http://bohoomil.com/ Infinality bundle & fonts]<br />
* '''Key-ID:''' 962DDE58<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle-fonts]<br />
Server = http://bohoomil.com/repo/fonts<br />
</nowiki>}}<br />
<br />
==== ivasilev ====<br />
<br />
* '''Maintainer:''' [http://ivasilev.net Ianis G. Vasilev]<br />
* '''Description:''' A variety of packages, mostly my own software and AUR builds.<br />
* '''Upstream page:''' http://ivasilev.net/pacman<br />
* '''Key-ID:''' 436BB513<br />
<br />
{{Note|I mantain 'any', 'i686' and 'x86_64' repos. Each of them includes packages from 'any'. $arch can be replaced with any of the three}}<br />
<br />
{{bc|<nowiki><br />
[ivasilev]<br />
Server = http://ivasilev.net/pacman/any<br />
# Server = http://ivasilev.net/pacman/$arch<br />
</nowiki>}}<br />
<br />
==== xyne-any ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for "any" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{Note|Use this repository only if there is no matching {{ic|[xyne-*]}} repository for your architecture.}}<br />
<br />
{{bc|<nowiki><br />
[xyne-any]<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
==== archlinuxgr-any ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' The Hellenic (Greek) unofficial Arch Linux repository with many interesting packages.<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr-any]<br />
Server = http://archlinuxgr.tiven.org/archlinux/any<br />
</nowiki>}}<br />
<br />
== Both i686 and x86_64 ==<br />
<br />
Repositories with both i686 and x86_64 versions. The {{ic|$arch}} variable will be set automatically by pacman.<br />
<br />
=== Signed ===<br />
<br />
==== archlinuxcn ====<br />
<br />
* '''Maintainers:''' [https://plus.google.com/+PhoenixNemo/ Phoenix Nemo (phoenixlzx)], Felix Yan (felixonmars, TU), [https://twitter.com/lilydjwg lilydjwg], and others<br />
* '''Description:''' Packages by the Chinese Arch Linux community (mostly signed)<br />
* '''Git Repo:''' https://github.com/archlinuxcn/repo<br />
* '''Key-ID:''' Once the repo is added, ''archlinuxcn-keyring'' package must be installed before any other.<br />
<br />
{{bc|<nowiki><br />
[archlinuxcn]<br />
Server = http://repo.archlinuxcn.org/$arch<br />
</nowiki>}}<br />
<br />
==== atom-editor-git ====<br />
<br />
* '''Maintainer:''' Matthew Stobbs<br />
* '''Upstream page:''' https://atom.io/<br />
* '''Description:''' The Atom Editor, created by the people behind github, to mimic Sublime Text.<br />
* '''Key-ID:''' 26EBCC57<br />
<br />
{{bc|<nowiki><br />
[atom-editor-git]<br />
Server = http://repo.stobbstechnical.com/$arch<br />
</nowiki>}}<br />
<br />
==== bbqlinux ====<br />
<br />
* '''Maintainer:''' [https://plus.google.com/u/0/+DanielHillenbrand/about Daniel Hillenbrand]<br />
* '''Description:''' Packages for Android Development<br />
* '''Upstream Page:''' http://bbqlinux.org/<br />
* '''Key-ID:''' Get the ''bbqlinux-keyring'' package, as it contains the needed keys.<br />
<br />
{{bc|<nowiki><br />
[bbqlinux]<br />
Server = http://packages.bbqlinux.org/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== catalyst ====<br />
<br />
* '''Maintainer:''' [[User:Vi0L0 | Vi0l0]]<br />
* '''Description:''' ATI Catalyst proprietary drivers.<br />
* '''Upstream Page:''' http://catalyst.wirephire.com<br />
* '''Key-ID:''' 653C3094<br />
<br />
{{bc|<nowiki><br />
[catalyst]<br />
Server = http://catalyst.wirephire.com/repo/catalyst/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://70.239.162.206/catalyst-mirror/repo/catalyst/$arch<br />
#Server = http://mirror.rts-informatique.fr/archlinux-catalyst/repo/catalyst/$arch<br />
#Server = http://mirror.hactar.bz/Vi0L0/catalyst/$arch<br />
</nowiki>}}<br />
<br />
==== catalyst-hd234k ====<br />
<br />
* '''Maintainer:''' [[User:Vi0L0 | Vi0l0]]<br />
* '''Description:''' ATI Catalyst proprietary drivers.<br />
* '''Upstream Page:''' http://catalyst.wirephire.com<br />
* '''Key-ID:''' 653C3094<br />
<br />
{{bc|<nowiki><br />
[catalyst-hd234k]<br />
Server = http://catalyst.wirephire.com/repo/catalyst-hd234k/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://70.239.162.206/catalyst-mirror/repo/catalyst-hd234k/$arch<br />
#Server = http://mirror.rts-informatique.fr/archlinux-catalyst/repo/catalyst-hd234k/$arch<br />
#Server = http://mirror.hactar.bz/Vi0L0/catalyst-hd234k/$arch<br />
</nowiki>}}<br />
<br />
==== city ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#bgyorgy Balló György]<br />
* '''Description:''' Experimental/unpopular packages.<br />
* '''Upstream page:''' http://pkgbuild.com/~bgyorgy/city.html<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[city]<br />
Server = http://pkgbuild.com/~bgyorgy/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== demz-repo-archiso ====<br />
<br />
* '''Maintainer:''' [http://demizerone.com Jesus Alvarez (demizer)]<br />
* '''Description:''' Packages for installing ZFS from an Arch ISO live disk<br />
* '''Upstream page:''' https://github.com/demizer/archzfs<br />
* '''Key-ID:''' 5E1ABF240EE7A126<br />
<br />
{{bc|<nowiki><br />
[demz-repo-archiso]<br />
Server = http://demizerone.com/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== demz-repo-core ====<br />
<br />
* '''Maintainer:''' [http://demizerone.com Jesus Alvarez (demizer)]<br />
* '''Description:''' Packages for ZFS on Arch Linux.<br />
* '''Upstream page:''' https://github.com/demizer/archzfs<br />
* '''Key-ID:''' 5E1ABF240EE7A126<br />
<br />
{{bc|<nowiki><br />
[demz-repo-core]<br />
Server = http://demizerone.com/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== gnome-encfs-manager ====<br />
<br />
* '''Maintainer:''' Moritz Molch<br />
* '''Description:''' The gnome-encfs-manager can be used to integrate [[EncFS]]<br />
* '''Upstream page:''' [https://launchpad.net/gencfsm Gnome EncfsM].<br />
* '''Key ID:'''<br />
<br />
{{bc|<nowiki><br />
[home_moritzmolch_gencfsm_Arch_Extra]<br />
Server = http://download.opensuse.org/repositories/home:/moritzmolch:/gencfsm/Arch_Extra/$arch<br />
</nowiki>}}<br />
<br />
==== haavard ====<br />
<br />
* '''Maintainer:''' Håvard Pettersson<br />
* '''Description:''' Mostly Tox-related packages<br />
* '''Upstream page:''' https://haavard.me/archlinux<br />
* '''Key-ID:''' 928988CE<br />
<br />
{{bc|<nowiki><br />
[haavard]<br />
Server = https://haavard.me/archlinux/$arch<br />
</nowiki>}}<br />
<br />
==== haskell-core ====<br />
<br />
* '''Maintainer:''' Magnus Therning<br />
* '''Description:''' Arch-Haskell repository<br />
* '''Upstream page:''' https://github.com/archhaskell/habs<br />
* '''Key-ID:''' 4209170B<br />
<br />
{{bc|<nowiki><br />
[haskell-core]<br />
Server = http://xsounds.org/~haskell/core/$arch<br />
</nowiki>}}<br />
<br />
==== infinality-bundle ====<br />
<br />
* '''Maintainer:''' [http://bohoomil.com/ bohoomil]<br />
* '''Description:''' infinality-bundle main repository.<br />
* '''Upstream page:''' [http://bohoomil.com/ Infinality bundle & fonts]<br />
* '''Key-ID:''' 962DDE58<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle]<br />
Server = http://bohoomil.com/repo/$arch<br />
</nowiki>}}<br />
<br />
==== ivasilev ====<br />
<br />
* '''Maintainer:''' [http://ivasilev.net Ianis G. Vasilev]<br />
* '''Description:''' A variety of packages, mostly my own software and AUR builds.<br />
* '''Upstream page:''' http://ivasilev.net/pacman<br />
* '''Key-ID:''' 436BB513<br />
<br />
{{Note|I mantain 'any', 'i686' and 'x86_64' repos. Each of them includes packages from 'any'. $arch can be replaced with any of the three}}<br />
<br />
{{bc|<nowiki><br />
[ivasilev]<br />
Server = http://ivasilev.net/pacman/$arch<br />
</nowiki>}}<br />
<br />
==== libre ====<br />
<br />
* '''Maintainer:''' Parabola Linux-libre<br />
* '''Description:''' Libre variations on Core/extra packages.<br />
* '''Upstream page:''' https://wiki.parabola.nu/Repositories#libre<br />
* '''Key-ID:''' https://www.parabola.nu/master-keys/<br />
<br />
{{Warning|Placing {{ic|[libre]}} before {{ic|[core]}} in {{ic|/etc/pacman.conf}} is '''not''' supported.}}<br />
<br />
{{Note|To install {{ic|parabola-keyring}}, {{ic|1=SigLevel = PackageOptional}} should be added temporarily.}}<br />
<br />
{{bc|<nowiki><br />
[libre]<br />
Server = https://repo.parabola.nu/libre/os/$arch<br />
</nowiki>}}<br />
<br />
==== lxqt-git ====<br />
<br />
* '''Maintainer:''' [http://www.stobbstechnical.com/ stobbsm]<br />
* '''Description:''' lxqt-git weekly build repository<br />
* '''Key-ID:''' 26EBCC57<br />
<br />
{{bc|<nowiki><br />
[lxqt-git]<br />
Server = http://repo.stobbstechnical.com/$arch<br />
</nowiki>}}<br />
<br />
==== metalgamer ====<br />
<br />
* '''Maintainer:''' [http://metalgamer.eu/ metalgamer]<br />
* '''Description:''' Packages I use and/or maintain on the AUR.<br />
* '''Key ID:''' F55313FB<br />
<br />
{{bc|<nowiki><br />
[metalgamer]<br />
Server = http://repo.metalgamer.eu/$arch<br />
</nowiki>}}<br />
<br />
==== miffe ====<br />
<br />
* '''Maintainer:''' [https://bbs.archlinux.org/profile.php?id=4059 miffe]<br />
* '''Description:''' AUR packages maintained by miffe, e.g. linux-mainline<br />
* '''Key ID:''' 313F5ABD<br />
<br />
{{bc|<nowiki><br />
[miffe]<br />
Server = http://arch.miffe.org/$arch/<br />
</nowiki>}}<br />
<br />
==== pipelight ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Pipelight and wine-compholio<br />
* '''Upstream page:''' [http://fds-team.de/ fds-team.de]<br />
* '''Key-ID:''' E49CC0415DC2D5CA<br />
* '''Keyfile:''' http://repos.fds-team.de/Release.key<br />
<br />
{{bc|<nowiki><br />
[pipelight]<br />
Server = http://repos.fds-team.de/stable/arch/$arch<br />
</nowiki>}}<br />
<br />
==== repo-ck ====<br />
<br />
* '''Maintainer:''' [[User:Graysky|graysky]]<br />
* '''Description:''' Kernel and modules with Brain Fuck Scheduler and all the goodies in the ck1 patch set.<br />
* '''Upstream page:''' [http://repo-ck.com repo-ck.com]<br />
* '''Wiki:''' [[repo-ck]]<br />
* '''Key-ID:''' 5EE46C4C<br />
<br />
{{bc|<nowiki><br />
[repo-ck]<br />
Server = http://repo-ck.com/$arch<br />
</nowiki>}}<br />
<br />
==== seblu ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/developers/#seblu Sébastien Luttringer]<br />
* '''Description:''' All seblu useful pre-built packages, some homemade (virtualbox-ext-oracle, linux-seblu-meta, bedup).<br />
* '''Key-ID:''' Not required, as maintainer is a Developer<br />
<br />
{{bc|<nowiki><br />
[seblu]<br />
Server = http://seblu.net/a/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== sergej-repo ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#spupykin Sergej Pupykin]<br />
* '''Description:''' psi-plus, owncloud-git, ziproxy, android, MySQL, and other stuff. Some packages also available for armv7h.<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[sergej-repo]<br />
Server = http://repo.p5n.pp.ru/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
{{Note|Users will need to add the following to these entries: {{ic|1=SigLevel = PackageOptional}}}}<br />
<br />
==== arch-deepin ====<br />
<br />
* '''Maintainer:''' [https://build.opensuse.org/project/show/home:metakcahura metak], [https://github.com/fasheng fasheng]<br />
* '''Description:''' Porting software from Linux Deepin to Archlinux.<br />
* '''Upstream page:''' https://github.com/fasheng/arch-deepin<br />
<br />
{{bc|<nowiki><br />
[home_metakcahura_arch-deepin_Arch_Extra]<br />
SigLevel = Never<br />
Server = http://download.opensuse.org/repositories/home:/metakcahura:/arch-deepin/Arch_Extra/$arch<br />
#Server = http://anorien.csc.warwick.ac.uk/mirrors/download.opensuse.org/repositories/home:/metakcahura:/arch-deepin/Arch_Extra/$arch<br />
</nowiki>}}<br />
<br />
==== archaudio ====<br />
<br />
* '''Maintainer:''' [[User:Schivmeister|Ray Rashif]], [https://aur.archlinux.org/account/jhernberg Joakim Hernberg]<br />
* '''Description:''' Pro-audio packages<br />
<br />
{{bc|<nowiki><br />
[archaudio-production]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archie-repo ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/Kalinda/ Kalinda]<br />
* '''Description:''' Repo for wine-silverlight, pipelight, and some misc packages.<br />
<br />
{{bc|<nowiki><br />
[archie-repo]<br />
Server = http://andontie.net/archie-repo/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxfr ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
* '''Upstream page:''' http://afur.archlinux.fr<br />
<br />
{{bc|<nowiki><br />
[archlinuxfr]<br />
Server = http://repo.archlinux.fr/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgis ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Maintainers needed - low bandwidth<br />
<br />
{{bc|<nowiki><br />
[archlinuxgis]<br />
Server = http://archlinuxgis.no-ip.org/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgr ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr]<br />
Server = http://archlinuxgr.tiven.org/archlinux/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgr-kde4 ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' KDE4 packages (plasmoids, themes etc) provided by the Hellenic (Greek) Arch Linux community<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr-kde4]<br />
Server = http://archlinuxgr.tiven.org/archlinux-kde4/$arch<br />
</nowiki>}}<br />
<br />
==== arsch ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' From users of orgizm.net<br />
<br />
{{bc|<nowiki><br />
[arsch]<br />
Server = http://arsch.orgizm.net/$arch<br />
</nowiki>}}<br />
<br />
==== aurbin ====<br />
<br />
{{Note|This Repository wasn't updated since October 2013}}<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Automated build of AUR packages<br />
* '''Upstream page:''' http://aurbin.net/<br />
<br />
{{bc|<nowiki><br />
[aurbin]<br />
Server = http://aurbin.net/$arch<br />
</nowiki>}}<br />
<br />
==== cinnamon ====<br />
<br />
* '''Maintainer:''' [https://github.com/jnbek jnbek]<br />
* '''Description:''' Stable and actively developed Cinnamon packages (Applets, Themes, Extensions), plus others (Hotot, qBitTorrent, GTK themes, Perl modules, and more).<br />
<br />
{{bc|<nowiki><br />
[cinnamon]<br />
Server = http://archlinux.zoelife4u.org/cinnamon/$arch<br />
</nowiki>}}<br />
<br />
==== ede ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Equinox Desktop Environment repository<br />
<br />
{{bc|<nowiki><br />
[ede]<br />
Server = http://ede.elderlinux.org/repos/archlinux/$arch<br />
</nowiki>}}<br />
<br />
==== heftig ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#heftig Jan Steffens]<br />
* '''Description:''' Includes linux-zen and aurora (Firefox development build - works alongside {{Pkg|firefox}} in the ''extra'' repository).<br />
* '''Upstream page:''' https://bbs.archlinux.org/viewtopic.php?id=117157<br />
<br />
{{bc|<nowiki><br />
[heftig]<br />
Server = http://pkgbuild.com/~heftig/repo/$arch<br />
</nowiki>}}<br />
<br />
==== herecura-stable ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' additional packages not found in the ''community'' repository<br />
<br />
{{bc|<nowiki><br />
[herecura-stable]<br />
Server = http://repo.herecura.be/herecura-stable/$arch<br />
</nowiki>}}<br />
<br />
==== herecura-testing ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' additional packages for testing build against stable arch<br />
<br />
{{bc|<nowiki><br />
[herecura-testing]<br />
Server = http://repo.herecura.be/herecura-testing/$arch<br />
</nowiki>}}<br />
<br />
==== mesa-git ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Mesa git builds for the ''testing'' and ''multilib-testing'' repositories<br />
<br />
{{bc|<nowiki><br />
[mesa-git]<br />
Server = http://pkgbuild.com/~lcarlier/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== noware ====<br />
<br />
* '''Maintainer:''' Alexandru Thirtheu (alex_giusi_tiri2@yahoo.com) ([https://bbs.archlinux.org/profile.php?id=65036 Forums]) ([https://wiki.archlinux.org/index.php/User:AGT Wiki]) ([http://noware.co Web Site])<br />
* '''Description:''' Software which I prefer being present in a repository, than being compiled each time. It eases software maintenance, I find. Almost anything goes.<br />
<br />
{{bc|<nowiki><br />
[noware]<br />
Server = http://noware.co/repository/arch/$arch<br />
</nowiki>}}<br />
<br />
==== openrc-eudev ====<br />
<br />
* '''Maintainer:''' [[User:Aaditya|Aaditya]], [[User:Nous|Nous]]<br />
* '''Description:''' OpenRC and eudev packages, [[OpenRC#artoo | artoo's way]].<br />
{{bc|<nowiki><br />
[openrc-eudev]<br />
Server = http://downloads.sourceforge.net/project/archopenrc/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== oracle ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Oracle database client<br />
<br />
{{Warning|By adding this you are agreeing to the Oracle license at http://www.oracle.com/technetwork/licenses/instant-client-lic-152016.html}}<br />
<br />
{{bc|<nowiki><br />
[oracle]<br />
Server = http://linux.shikadi.net/arch/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== pantheon ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#alucryd Maxime Gauduin]<br />
* '''Description:''' Repository containing Pantheon-related packages<br />
<br />
{{bc|<nowiki><br />
[pantheon]<br />
Server = http://pkgbuild.com/~alucryd/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== paulburton-fitbitd ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Contains fitbitd for synchronizing FitBit trackers<br />
<br />
{{bc|<nowiki><br />
[paulburton-fitbitd]<br />
Server = http://www.paulburton.eu/arch/fitbitd/$arch<br />
</nowiki>}}<br />
<br />
==== pfkernel ====<br />
<br />
* '''Maintainer:''' [[User:Nous|nous]]<br />
* '''Description:''' Generic and optimized binaries of the ARCH kernel patched with BFS, TuxOnIce, BFQ, Aufs3; i.e. linux-pf[-cpu] and linux-pf-lts[-cpu]. Also, openrc and initscripts-openrc.<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/11734958/x86_64/index.html or start at http://tiny.cc/linux-pf<br />
<br />
{{bc|<nowiki><br />
[pfkernel]<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
</nowiki>}}<br />
<br />
==== rstudio ====<br />
<br />
* '''Maintainer:''' Artem Klevtsov <a.a.klevtsov@gmail.com><br />
* '''Description:''' Rstudio IDE package (git version) and depends.<br />
<br />
{{bc|<nowiki><br />
[rstudio]<br />
Server = http://rstudio.archer.tw/$arch<br />
</nowiki>}}<br />
<br />
==== suckless ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' suckless.org packages<br />
<br />
{{bc|<nowiki><br />
[suckless]<br />
Server = http://dl.suckless.org/arch/$arch<br />
</nowiki>}}<br />
<br />
==== unity ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity packages for Arch<br />
<br />
{{bc|<nowiki><br />
[unity]<br />
Server = http://unity.xe-xe.org/$arch<br />
</nowiki>}}<br />
<br />
==== unity-extra ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity extra packages for Arch<br />
<br />
{{bc|<nowiki><br />
[unity-extra]<br />
Server = http://unity.xe-xe.org/extra/$arch<br />
</nowiki>}}<br />
<br />
==== home_tarakbumba_archlinux_Arch_Extra_standard ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Contains a few pre-built AUR packages (zemberek, firefox-kde-opensuse, etc.)<br />
<br />
{{bc|<nowiki><br />
[home_tarakbumba_archlinux_Arch_Extra_standard]<br />
Server = http://download.opensuse.org/repositories/home:/tarakbumba:/archlinux/Arch_Extra_standard/$arch<br />
</nowiki>}}<br />
<br />
== i686 only ==<br />
<br />
=== Signed ===<br />
<br />
==== eee-ck ====<br />
<br />
* '''Maintainer:''' Gruppenpest<br />
* '''Description:''' Kernel and modules optimized for Asus Eee PC 701, with -ck patchset.<br />
* '''Key-ID:''' 27D4A19A<br />
* '''Keyfile''' http://zembla.duckdns.org/repo/gruppenpest.gpg<br />
<br />
{{bc|<nowiki><br />
[eee-ck]<br />
Server = http://zembla.duckdns.org/repo<br />
</nowiki>}}<br />
<br />
==== phillid ====<br />
<br />
* '''Maintainer:''' Phillid<br />
* '''Description:''' Various GCC-s and matching binutils-es which target bare-bones formats (for OS dev). The GCC toolchains are shrunk to ~8&nbsp;MiB each by disabling NLS and everything but the C front-end. Thrown in there is some ham-related stuff I use such as hamlib, xastir, qsstv. Also a couple of legacy packages which are a bit lengthy to build for most people (kdelibs3, qt3).<br />
* '''Key-ID:''' 28F1E6CE<br />
<br />
{{bc|<nowiki><br />
[phillid]<br />
Server = http://phillid.tk/r/i686/<br />
</nowiki>}}<br />
<br />
==== xyne-i686 ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for the "i686" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{Note|This includes all packages in [[#xyne-any|<nowiki>[xyne-any]</nowiki>]].}}<br />
<br />
{{bc|<nowiki><br />
[xyne-i686]<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
==== andrwe ====<br />
<br />
* '''Maintainer:''' Andrwe Lord Weber<br />
* '''Description:''' each program I'm using on x86_64 is compiled for i686 too<br />
* '''Upstream page:''' http://andrwe.org/linux/repository<br />
<br />
{{bc|<nowiki><br />
[andrwe]<br />
Server = http://repo.andrwe.org/i686<br />
</nowiki>}}<br />
<br />
==== esclinux ====<br />
<br />
{{Note|Off-line since 2014-07-02.}}<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Mostly games, interactive fiction, and abc notation stuff already on the AUR.<br />
<br />
{{bc|<nowiki><br />
[esclinux]<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
</nowiki>}}<br />
<br />
==== kpiche ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Stable OpenSync packages.<br />
<br />
{{bc|<nowiki><br />
[kpiche]<br />
Server = http://kpiche.archlinux.ca/repo<br />
</nowiki>}}<br />
<br />
==== kernel26-pae ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' PAE-enabled 32-bit kernel 2.6.39<br />
<br />
{{bc|<nowiki><br />
[kernel26-pae]<br />
Server = http://kernel26-pae.archlinux.ca/<br />
</nowiki>}}<br />
<br />
==== linux-pae ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' PAE-enabled 32-bit kernel 3.0<br />
<br />
{{bc|<nowiki><br />
[linux-pae]<br />
Server = http://pae.archlinux.ca/<br />
</nowiki>}}<br />
<br />
==== rfad ====<br />
<br />
* '''Maintainer:''' requiem [at] archlinux.us<br />
* '''Description:''' Repository made by haxit<br />
<br />
{{bc|<nowiki><br />
[rfad]<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
</nowiki>}}<br />
<br />
==== studioidefix ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Precompiled boxee packages.<br />
<br />
{{bc|<nowiki><br />
[studioidefix]<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
</nowiki>}}<br />
<br />
== x86_64 only ==<br />
<br />
=== Signed ===<br />
<br />
==== apathism ====<br />
<br />
* '''Maintainer:''' Koryabkin Ivan ([https://aur.archlinux.org/account/apathism/ apathism])<br />
* '''Upstream page:''' https://apathism.net/<br />
* '''Description:''' AUR packages that would take long to build, such as {{AUR|firefox-kde-opensuse}}.<br />
* '''Key-ID:''' 3E37398D<br />
* '''Keyfile:''' http://apathism.net/archlinux/apathism.key<br />
<br />
{{bc|<nowiki><br />
[apathism]<br />
Server = http://apathism.net/archlinux/<br />
</nowiki>}}<br />
<br />
==== bioinformatics ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/decryptedepsilon/ decryptedepsilon]<br />
* '''Description:''' A repository containing some software tools for Bioinformatics<br />
* '''Key-ID:''' 60442BA4<br />
<br />
{{bc|<nowiki><br />
[bioinformatics]<br />
Server = http://decryptedepsilon.bl.ee/repo/x86_64<br />
</nowiki>}}<br />
<br />
==== boyska64 ====<br />
<br />
* '''Maintainer:''' boyska<br />
* '''Description:''' Personal repository: cryptography, sdr, mail handling and misc<br />
* '''Key-ID:''' 0x7395DCAE58289CA9<br />
<br />
{{bc|<nowiki><br />
[boyska64]<br />
Server = http://boyska.s.pt-labs.net/archrepo<br />
</nowiki>}}<br />
<br />
==== carstene1ns ====<br />
<br />
* '''Maintainer:''' [[User:Carstene1ns|Carsten Teibes]]<br />
* '''Description:''' AUR packages maintained and/or used by carstene1ns (games/Wii/lib32/Python)<br />
* '''Upstream page:''' http://repo.carsten-teibes.de<br />
* '''Key-ID:''' 2476B20B<br />
<br />
{{bc|<nowiki><br />
[carstene1ns]<br />
Server = http://repo.carsten-teibes.de/$arch<br />
</nowiki>}}<br />
<br />
==== coderkun-aur ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with random software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://arch.coderkun.de<br />
* '''Key-ID:''' A6BEE374<br />
* '''Keyfile:''' [http://arch.coderkun.de/coderkun.asc http://arch.coderkun.de/coderkun.asc]<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur]<br />
Server = http://arch.coderkun.de/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== coderkun-aur-audio ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with audio-related (realtime kernels, lv2-plugins, …) software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://arch.coderkun.de<br />
* '''Key-ID:''' A6BEE374<br />
* '''Keyfile:''' [http://arch.coderkun.de/coderkun.asc http://arch.coderkun.de/coderkun.asc]<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur-audio]<br />
Server = http://arch.coderkun.de/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== coderkun-aur-java ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with java related software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://arch.coderkun.de<br />
* '''Key-ID:''' A6BEE374<br />
* '''Keyfile:''' [http://arch.coderkun.de/coderkun.asc http://arch.coderkun.de/coderkun.asc]<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur-java]<br />
Server = http://arch.coderkun.de/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== coderkun-aur-nonfree ====<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with proprietary (dropbox, nvidia, …) software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://arch.coderkun.de<br />
* '''Key-ID:''' A6BEE374<br />
* '''Keyfile:''' [http://arch.coderkun.de/coderkun.asc http://arch.coderkun.de/coderkun.asc]<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur-nonfree]<br />
Server = http://arch.coderkun.de/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== freifunk-rheinland ====<br />
<br />
* '''Maintainer:''' nomaster<br />
* '''Description:''' Packages for the Freifunk project: batman-adv, batctl, fastd and dependencies.<br />
<br />
{{bc|<nowiki><br />
[freifunk-rheinland]<br />
Server = http://mirror.fluxent.de/archlinux-custom/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== gustawho ====<br />
<br />
* '''Maintainer:''' [https://twitter.com/gustawho Gustavo Castro]<br />
* '''Description:''' Scientific tools (mostly physics/math, e.g. {{AUR|quantum-espresso}}) and AUR packages that would take long to build, such as {{AUR|firefox-gtk3}}, {{AUR|firefox-kde-opensuse}} and {{AUR|jdk7-openjdk-infinality}} ([http://gustawho.com/recent-updates/ package list]).<br />
* '''Upstream page:''' http://gustawho.com<br />
* '''Key-ID:''' 2C575D76<br />
<br />
{{bc|<nowiki><br />
[gustawho]<br />
Server = http://gustawho.com/repo/x86_64<br />
</nowiki>}}<br />
<br />
==== Linux-pf ====<br />
<br />
{{Accuracy|Signed repositories should not use {{ic|1=SigLevel = Optional}} (by definition).}}<br />
<br />
* '''Maintainer:''' [[User:Thaodan|Thaodan]]<br />
* '''Description:''' Generic and optimized binaries of the ARCH kernel patched with BFS, TuxOnIce, BFQ, Aufs3; i.e. linux-pf, just like {{AUR|linux-pf}} from the [[AUR]] but additionally optimized for intel CPUs Sandy Bridge, Ivy Bridge, Haswell and generic of course, and some extra packages<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox).<br />
<br />
{{bc|<nowiki><br />
[Linux-pf]<br />
Server = https://dl.dropboxusercontent.com/u/172590784/Linux-pf/x86_64/<br />
SigLevel = Optional<br />
</nowiki>}}<br />
<br />
==== infinality-bundle-multilib ====<br />
<br />
* '''Maintainer:''' [http://bohoomil.com/ bohoomil]<br />
* '''Description:''' infinality-bundle multilib repository.<br />
* '''Upstream page:''' [http://bohoomil.com/ Infinality bundle & fonts]<br />
* '''Key-ID:''' 962DDE58<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle-multilib]<br />
Server = http://bohoomil.com/repo/multilib/$arch<br />
</nowiki>}}<br />
<br />
==== kc9ydn ====<br />
<br />
* '''Maintainer:''' [http://kc9ydn.us KC9YDN]<br />
* '''Description:''' Consists mostly of amateur radio related apps<br />
* '''Key-ID:''' 7DA25A0F<br />
<br />
{{bc|<nowiki><br />
[kc9ydn]<br />
Server = http://kc9ydn.us/repo/<br />
</nowiki>}}<br />
<br />
==== linux-lts-ck ====<br />
<br />
* '''Maintainer:''' Claire Farron [https://aur.archlinux.org/account/clfarron4 clfarron4]<br />
* '''Description:''' Current ArchLinux LTS kernel with the CK patch<br />
* '''Key-ID:''' E6366A92<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/298301785/arch/linux-lts-ck/x86_64/index.html or start at http://tiny.cc/linux-lts-ck<br />
<br />
{{bc|<nowiki><br />
[linux-lts-ck]<br />
Server = http://dl.dropbox.com/u/298301785/arch/linux-lts-ck/$arch<br />
</nowiki>}}<br />
<br />
==== linux-lts31x ====<br />
<br />
* '''Maintainer:''' Claire Farron [https://aur.archlinux.org/account/clfarron4 clfarron4]<br />
* '''Description:''' Older LTS kernels (3.10 and 3.12 branch)<br />
* '''Key-ID:''' E6366A92<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/298301785/arch/linux-lts31x/x86_64/index.html or start at http://tiny.cc/linux-lts31x<br />
<br />
{{bc|<nowiki><br />
[linux-lts31x]<br />
Server = http://dl.dropbox.com/u/298301785/arch/linux-lts31x/$arch<br />
</nowiki>}}<br />
<br />
==== linux-lts31x-ck ====<br />
<br />
* '''Maintainer:''' Claire Farron [https://aur.archlinux.org/account/clfarron4 clfarron4]<br />
* '''Description:''' Older LTS kernels (3.10 and 3.12 branch) with the CK patch<br />
* '''Key-ID:''' E6366A92<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/298301785/arch/linux-lts31x-ck/x86_64/index.html or start at http://tiny.cc/linux-lts31x-ck<br />
<br />
{{bc|<nowiki><br />
[linux-lts31x-ck]<br />
Server = http://dl.dropbox.com/u/298301785/arch/linux-lts31x-ck/$arch<br />
</nowiki>}}<br />
<br />
==== linux-ck-pax ====<br />
<br />
* '''Maintainer:''' Claire Farron [https://aur.archlinux.org/account/clfarron4 clfarron4]<br />
* '''Description:''' Current Arch Kernel with the CK and PaX security patchsets<br />
* '''Key-ID:''' E6366A92<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/298301785/arch/linux-ck-pax/x86_64/index.html or start at http://tiny.cc/linux-ck-pax<br />
<br />
{{bc|<nowiki><br />
[linux-ck-pax]<br />
Server = http://dl.dropbox.com/u/298301785/arch/linux-ck-pax/$arch<br />
</nowiki>}}<br />
<br />
==== linux-tresor ====<br />
<br />
* '''Maintainer:''' Claire Farron [https://aur.archlinux.org/account/clfarron4 clfarron4]<br />
* '''Description:''' Arch Current and LTS kernels with TRESOR<br />
* '''Key-ID:''' E6366A92<br />
* '''Note:''' To browse through the repository, one needs to append {{ic|index.html}} after the server URL (this is an intentional quirk of Dropbox). For example, for x86_64, point your browser to http://dl.dropbox.com/u/298301785/arch/linux-tresor/x86_64/index.html or start at http://tiny.cc/linux-tresor<br />
<br />
{{bc|<nowiki><br />
[linux-tresor]<br />
Server = http://dl.dropbox.com/u/298301785/arch/linux-tresor/$arch<br />
</nowiki>}}<br />
<br />
==== qt-debug ====<br />
<br />
* '''Maintainer:''' [http://blog.the-compiler.org/?page_id=36 The Compiler]<br />
* '''Description:''' Qt/PyQt builds with debug symbols<br />
* '''Upstream page:''' https://github.com/The-Compiler/qt-debug-pkgbuild<br />
* '''Key-ID:''' D6A1C70FE80A0C82<br />
<br />
{{bc|<nowiki><br />
[qt-debug]<br />
Server = http://qutebrowser.org/qt-debug/$arch<br />
</nowiki>}}<br />
<br />
==== quarry ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/developers/#anatolik anatolik]<br />
* '''Description:''' Arch binary repository for [http://rubygems.org/ Rubygems] packages. See [https://bbs.archlinux.org/viewtopic.php?id=182729 forum announcement] for more information.<br />
* '''Sources:''' https://github.com/anatol/quarry<br />
* '''Key-ID:''' Not needed, as maintainer is a developer<br />
<br />
{{bc|<nowiki><br />
[quarry]<br />
# report issues at https://github.com/anatol/quarry<br />
Server = http://pkgbuild.com/~anatolik/quarry/x86_64/<br />
</nowiki>}}<br />
<br />
==== siosm-aur ====<br />
<br />
* '''Maintainer:''' [https://tim.siosm.fr/about/ Timothee Ravier]<br />
* '''Description:''' packages also available in the Arch User Repository, sometimes with minor fixes<br />
* '''Upstream page:''' https://tim.siosm.fr/repositories/<br />
* '''Key-ID:''' 78688F83<br />
<br />
{{bc|<nowiki><br />
[siosm-aur]<br />
Server = http://siosm.fr/repo/$repo/<br />
</nowiki>}}<br />
<br />
==== siosm-selinux ====<br />
<br />
* '''Maintainer:''' [https://tim.siosm.fr/about/ Timothee Ravier]<br />
* '''Description:''' packages required for SELinux support – work in progress (notably, missing an Arch Linux-compatible SELinux policy). See the [[SELinux]] page for details.<br />
* '''Upstream page:''' https://tim.siosm.fr/repositories/<br />
* '''Key-ID:''' 78688F83<br />
<br />
{{bc|<nowiki><br />
[siosm-selinux]<br />
Server = http://siosm.fr/repo/$repo/<br />
</nowiki>}}<br />
<br />
==== subtitlecomposer ====<br />
<br />
* '''Maintainer:''' Mladen Milinkovic (maxrd2)<br />
* '''Description:''' Subtitle Composer stable and nightly builds<br />
* '''Upstream page:''' https://github.com/maxrd2/subtitlecomposer<br />
* '''Key-ID:''' EA8CEBEE<br />
<br />
{{bc|<nowiki><br />
[subtitlecomposer]<br />
Server = http://smoothware.net/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== xyne-x86_64 ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for the "x86_64" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{Note|This includes all packages in [[#xyne-any|<nowiki>[xyne-any]</nowiki>]].}}<br />
<br />
{{bc|<nowiki><br />
[xyne-x86_64]<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
{{Note|Users will need to add the following to these entries: {{ic|1=SigLevel = PackageOptional}}}}<br />
<br />
==== alucryd ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#alucryd Maxime Gauduin]<br />
* '''Description:''' Various packages Maxime Gauduin maintains (or not) in the AUR.<br />
<br />
{{bc|<nowiki><br />
[alucryd]<br />
Server = http://pkgbuild.com/~alucryd/$repo/x86_64<br />
</nowiki>}}<br />
<br />
==== alucryd-multilib ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#alucryd Maxime Gauduin]<br />
* '''Description:''' Various packages needed to run Steam without its runtime environment.<br />
<br />
{{bc|<nowiki><br />
[alucryd-multilib]<br />
Server = http://pkgbuild.com/~alucryd/$repo/x86_64<br />
</nowiki>}}<br />
<br />
==== andrwe ====<br />
<br />
* '''Maintainer:''' Andrwe Lord Weber<br />
* '''Description:''' contains programs I'm using on many systems<br />
* '''Upstream page:''' http://andrwe.dyndns.org/doku.php/blog/repository {{Dead link|2013|11|30}}<br />
<br />
{{bc|<nowiki><br />
[andrwe]<br />
Server = http://repo.andrwe.org/x86_64<br />
</nowiki>}}<br />
<br />
==== archstudio ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Audio and Music Packages optimized for Intel Core i3, i5, and i7.<br />
* '''Upstream page:''' http://www.xsounds.org/~archstudio<br />
<br />
{{bc|<nowiki><br />
[archstudio]<br />
Server = http://www.xsounds.org/~archstudio/x86_64<br />
</nowiki>}}<br />
<br />
==== brtln ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#bpiotrowski Bartłomiej Piotrowski]<br />
* '''Description:''' Some VCS packages.<br />
<br />
{{bc|<nowiki><br />
[brtln]<br />
Server = http://pkgbuild.com/~barthalion/brtln/$arch/<br />
</nowiki>}}<br />
<br />
==== kps ====<br />
<br />
* '''Maintainer:''' kps<br />
* '''Description:''' gmt, catalyst-test, ttf-ms-win8, rstudio, meshlab, gcc-gcj, vlc-git, ffmpeg-git (k10 & intel opt.), docear, maperitive, libressl, bkchem ...<br />
<br />
{{bc|<nowiki><br />
[kps]<br />
Server = http://kps.bplaced.net/repo/$arch<br />
</nowiki>}}<br />
<br />
==== pnsft-pur ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Japanese input method packages Mozc (vanilla) and libkkc<br />
<br />
{{bc|<nowiki><br />
[pnsft-pur]<br />
Server = http://downloads.sourceforge.net/project/pnsft-aur/pur/x86_64<br />
</nowiki>}}<br />
<br />
==== mingw-w64 ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Almost all mingw-w64 packages in the AUR updated every 8 hours.<br />
* '''Upstream page:''' http://arch.linuxx.org<br />
<br />
{{bc|<nowiki><br />
[mingw-w64]<br />
Server = http://downloads.sourceforge.net/project/mingw-w64-archlinux/$arch<br />
# in 2014-12-24 it seems no one worked<br />
#Server = http://arch.linuxx.org/archlinux/$repo/os/$arch<br />
#Server = http://amr.linuxd.org/archlinux/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== rakudo ====<br />
<br />
* '''Maintainer:''' spider-mario <spidermario@free.fr><br />
* '''Description:''' Rakudo Perl6<br />
<br />
{{bc|<nowiki><br />
[rakudo]<br />
Server = http://spidermario.free.fr/archlinux/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== rightlink ====<br />
<br />
* '''Maintainer:''' Chris Fordham <chris@fordham-nagy.id.au><br />
* '''Description:''' RightLink version 10 (RL10) is a new version of RightScale's server agent that connects servers managed through RightScale to the RightScale cloud management platform.<br />
<br />
{{bc|<nowiki><br />
[rightlink]<br />
Server = https://s3-ap-southeast-2.amazonaws.com/archlinux.rightscale.me/repo<br />
</nowiki>}}<br />
<br />
==== seiichiro ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' VDR and some plugins, mms, foo2zjs-drivers<br />
<br />
{{bc|<nowiki><br />
[seiichiro]<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
</nowiki>}}<br />
<br />
==== studioidefix ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Precompiled boxee packages.<br />
<br />
{{bc|<nowiki><br />
[studioidefix]<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
</nowiki>}}<br />
<br />
== armv6h only ==<br />
<br />
=== Unsigned ===<br />
<br />
==== arch-fook-armv6h ====<br />
<br />
* '''Maintainer:''' Jaska Kivelä <jaska@kivela.net><br />
* '''Description:''' Stuff that I have compiled for my Raspberry PI. Including Enlightenment and home automation stuff.<br />
<br />
{{bc|<nowiki><br />
[arch-fook-armv6h]<br />
Server = http://kivela.net/jaska/arch-fook-armv6h<br />
</nowiki>}}</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Seafile&diff=355888Seafile2015-01-08T14:30:33Z<p>Kopfweh: </p>
<hr />
<div>[[Category:Web Server]]<br />
{{Stub|Work in progress}}<br />
<br />
Seafile is an open source cloud storage system, with advanced support for file syncing, privacy protection and teamwork.<br />
<br />
Collections of files are called libraries, and each library can be synced separately. A library can be encrypted with a user chosen password. This password is not stored on the server, so even the server admin can't view your file contents.<br />
<br />
Seafile lets you create groups with file syncing, wiki, and discussion -- enabling easy collaboration around documents within a team.<br />
<br />
== Server ==<br />
<br />
=== Installation ===<br />
<br />
Install {{AUR|seafile-server}} from the [[Arch User Repository]]<br />
<br />
As root, add a new user to run seafile server instances under:<br />
<br />
# useradd -m -r -d /srv/seafile -s /bin/nologin seafile<br />
<br />
=== Setup a server instance ===<br />
<br />
Change to the user previously setup in [[#Installation]] (following commands are to be executed as that user unless otherwise stated):<br />
<br />
$ sudo -u seafile -s /bin/sh<br />
<br />
As that user, create the directory layout for the new seafile server instance and change directory to it:<br />
<br />
$ mkdir -p $HOME/example.org/seafile-server<br />
$ cd $HOME/example.org<br />
<br />
'''''Note:''''' '''Replace every occurence of 'example.org' on this page with the actual domain of your new server instance'''<br />
<br />
Determine the appropriate seahub version (it will be shown in the format 'x.y.z-r', e.g. 3.0.2):<br />
<br />
$ pacman -Qi seafile-server | grep Version<br />
<br />
Set the SEAFILE_SERVER_VERSION variable to the 'x.y.z' retrieved in the previous step:<br />
<br />
$ SEAFILE_SERVER_VERSION=3.0.3<br />
<br />
Download seahub and extract it:<br />
<br />
$ wget -P seafile-server https://github.com/haiwen/seahub/archive/v$SEAFILE_SERVER_VERSION-server.tar.gz<br />
$ tar -xz -C seafile-server -f seafile-server/v$SEAFILE_SERVER_VERSION-server.tar.gz<br />
<br />
Rename the extracted directory:<br />
<br />
$ mv seafile-server/seahub-$SEAFILE_SERVER_VERSION-server seafile-server/seahub<br />
<br />
To create the configuration for the seafile server instance choose and follow the 'setup' section of one of the following options shown in the [http://manual.seafile.com/deploy/README.html seafile manual]:<br />
* [http://manual.seafile.com/deploy/using_sqlite.html SQLite]<br />
* [http://manual.seafile.com/deploy/using_mysql.html MySQL]<br />
<br />
<br />
<br />
Now, copy the systemd service for seafile 'seafile-server@.service' from /usr/lib/systemd/system/ to /etc/systemd/system and replace the two occurences of '%h' in it with the actual $HOME for the user setup in [[#Installation]].<br />
<br />
If you did not yet setup nginx and if you want to test out seafiles own web-frontend-implementation seahub purely, you have to edit the systemd-service file, were you replaced the '%h' with your $HOME, and delete the --fastcgi parameter from the start script, as fastcgi is not supported with seahub-only.<br />
<br />
To manually start your new seafile server, run as root:<br />
<br />
# systemctl start seafile-server@example.org<br />
<br />
To automatically start your new seafile server at system startup, run as root:<br />
<br />
# systemctl enable seafile-server@example.org<br />
<br />
=== Deploy an instance with Nginx ===<br />
<br />
In order to deploy Seafile's webinterface "seahub" with Nginx, you can use an Nginx configuration similar to this:<br />
<br />
{{bc|<br />
server {<br />
listen 80;<br />
server_name www.example.org example.org;<br />
<nowiki>rewrite ^/(.*) https://$server_name/$1 permanent; # force redirect http to https</nowiki><br />
}<br />
<br />
server {<br />
listen 443;<br />
ssl on;<br />
ssl_certificate /etc/ssl/certs/example.org.crt;<br />
ssl_certificate_key /etc/ssl/private/server.key;<br />
server_name www.example.org example.org;<br />
<br />
location / {<br />
fastcgi_pass 127.0.0.1:8000;<br />
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;<br />
fastcgi_param PATH_INFO $fastcgi_script_name;<br />
<br />
fastcgi_param SERVER_PROTOCOL $server_protocol;<br />
fastcgi_param QUERY_STRING $query_string;<br />
fastcgi_param REQUEST_METHOD $request_method;<br />
fastcgi_param CONTENT_TYPE $content_type;<br />
fastcgi_param CONTENT_LENGTH $content_length;<br />
fastcgi_param SERVER_ADDR $server_addr;<br />
fastcgi_param SERVER_PORT $server_port;<br />
fastcgi_param SERVER_NAME $server_name;<br />
<br />
fastcgi_param HTTPS on;<br />
fastcgi_param HTTP_SCHEME https;<br />
}<br />
<br />
location /seafhttp {<br />
rewrite ^/seafhttp(.*)$ $1 break;<br />
<nowiki>proxy_pass http://127.0.0.1:8082;</nowiki><br />
client_max_body_size 0;<br />
}<br />
<br />
location /media {<br />
root {ABSOLUTE_PATH_TO_SEAFILE_USER'S_HOME}/example.org/seafile-server/seahub;<br />
}<br />
}<br />
}}<br />
<br />
=== Upgrading ===<br />
<br />
First, stop each of your seafile server instances (repeat for example.org, foo.bar, etc.) as root:<br />
<br />
# systemctl stop seafile-server@example.org<br />
<br />
Upgrade {{AUR|seafile-server}} from the [[Arch User Repository]].<br />
<br />
Become the user the seafile server instances run as (following commands are to be executed as that user unless otherwise stated):<br />
<br />
$ sudo -u seafile -s<br />
<br />
Repeat the following for each seafile server instance:<br />
<br />
: Change directory to the server instance's 'seafile-server' subdirectory:<br />
<br />
$ cd /srv/seafile/example.org/seafile-server<br />
<br />
: Run the preupgrade script (Or do the steps by hand, see [https://github.com/haiwen/seafile/wiki/Build-and-deploy-seafile-server-from-source the Seafile wiki]):<br />
<br />
$ seahub-preupgrade<br />
<br />
: Run the appropriate seafile/seahub upgrade script from the upgrade subdirectory:<br />
<br />
:: For a minor upgrade (x.y.a to x.y.b with a < b):<br />
<br />
$ ./upgrade/minor-upgrade.sh<br />
<br />
:: For a major upgrade (x.y.a to z.w.b with x < z || y < w):<br />
<br />
$ ./upgrade/upgrade_x.y_z.w.sh<br />
<br />
Lastly, start each of your seafile server instances again (repeat for example.org, foo.bar, etc.) as root:<br />
<br />
# systemctl start seafile-server@example.org<br />
<br />
== Sources ==<br />
* http://manual.seafile.com/deploy/README.html<br />
* http://manual.seafile.com/deploy/deploy_with_nginx.html</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Gerbera&diff=354544Gerbera2014-12-30T19:04:38Z<p>Kopfweh: Tried to deconfuse confusing sentence.</p>
<hr />
<div>[[Category:Streaming]]<br />
{{Related articles start}}<br />
{{Related|Streaming media}}<br />
{{Related articles end}}<br />
<br />
From [http://mediatomb.cc/ MediaTomb - Free UPnP MediaServer]:<br />
<br />
:''MediaTomb is an open source (GPL) UPnP MediaServer with a nice web user interface, it allows you to stream your digital media through your home network and listen to/watch it on a variety of UPnP compatible devices.''<br />
<br />
MediaTomb enables users to stream digital media to UPnP compatible devices like the PlayStation 3 (the Xbox 360 is not yet supported). Several alternatives exist, such as [http://sourceforge.net/projects/fuppes FUPPES], [http://code.google.com/p/ps3mediaserver/ ps3mediaserver], and [[uShare]]. One of MediaTomb's distinguishing features is the ability to customize the server layout based on extracted metadata (scriptable virtual containers); MediaTomb is highly flexible.<br />
<br />
== Installation ==<br />
<br />
MediaTomb is available in the [[AUR]] via {{AUR|mediatomb}}.<br />
<br />
The latest development version is also available in the [[AUR]] via {{AUR|mediatomb-git}}.<br />
<br />
Mediatomb can use its own database, or your local [[MariaDB]] server. For more information about the [[MariaDB]] integration visit the [http://mediatomb.cc/pages/documentation#id2855459 Documentation].<br />
<br />
== Configuration ==<br />
<br />
The default settings may be sufficient for many users, though changes are required for PlayStation 3 support. MediaTomb may be configured and run per-user or as a system-wide daemon. Following installation, either run<br />
<br />
$ mediatomb<br />
<br />
to start MediaTomb as the current user and generate a default configuration in {{ic|~/.mediatomb/config.xml}}, or<br />
<br />
# systemctl start mediatomb<br />
<br />
to start the MediaTomb daemon and generate a default configuration in {{ic|/var/lib/mediatomb/.mediatomb/config.xml}}.<br />
<br />
If you want to use the [[MariaDB]] database backend, you can alternatively run<br />
<br />
# systemctl start mediatomb-mariadb<br />
<br />
which will ensure that [[MariaDB]] is up and running before MediaTomb is.<br />
<br />
<br />
<br />
== Usage ==<br />
<br />
The daemon listens on port 50500 by default. To access the web interface and begin importing media, navigate to http://127.0.0.1:50500/ in your favorite browser (JavaScript required).<br />
<br />
If running per-user instances of MediaTomb, the default port is 49152. However, it is possible that the port will change upon server restart. The URL for the web interface is output during startup. Users may also specify the port manually:<br />
<br />
$ mediatomb -p 50500<br />
<br />
<br />
== Hiding full paths from media players ==<br />
<br />
By default, full directory paths will be shown on devices when they are browsing through folders.<br />
<br />
For example, if you add the directory /media/my_media/video_data/videos/movies, anyone connecting will have to navigate to the 'movies' directory from the root.<br />
<br />
To hide all of that and only show the directory added, you can change the import script.<br />
<br />
For example, this script will automatically truncate the whole directory structure specified in the variable video_root. Any directories added directly under the video root path will show up on UPnP devices starting from the that folder rather than /.<br />
<br />
function addVideo(obj)<br />
{<br />
var video_root = "/media/main_core/Server_Core_Folder/FTP_Services/Media/";<br />
<br />
var absolute_path = obj.location;<br />
<br />
var relative_path = absolute_path;<br />
<br />
if(absolute_path.indexOf(video_root) == 0)<br />
relative_path = absolute_path.replace(video_root, "")<br />
<br />
var chain = new Array();<br />
<br />
var pathSplit = relative_path.split("/");<br />
<br />
for(var i = 0; i < pathSplit.length - 1; i++) <br />
chain.push(pathSplit[i]);<br />
<br />
addCdsObject(obj, createContainerChain(chain));<br />
}<br />
<br />
To also hide the default PC Directory folder from UPnP device directory listings, add the following directly under the server node of your config.xml file.<br />
<br />
<pc-directory upnp-hide="yes"/><br />
<br />
<br />
== Playstation 3 Support ==<br />
<br />
The following notes assume MediaTomb is running as a system-wide daemon. For a per-user install, the locations of the configuration file will be different (see above).<br />
<br />
For PlayStation 3 support, users must set {{Ic|<nowiki><protocolInfo extend="yes"/></nowiki>}}. An "avi" mimetype mapping should also be uncommented for DivX support.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<protocolInfo extend="yes"/><br />
<br />
...<br />
<br />
<map from="avi" to="video/divx"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
When importing media to the database, MediaTomb will create a virtual container layout as defined by the {{Ic|<nowiki><virtual-layout type="..."></nowiki>}} option. That is, media will be organized according to metadata (album, artist, etc.) through creation of virtual database objects. If your media is already organized on the file system, you may disable this feature to significantly improve import performance:<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<virtual-layout type="disabled"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
Users may customize the import script to fine-tune the virtual layout. The [http://mediatomb.cc/dokuwiki/scripting:scripting Scripting] section of the MediaTomb wiki provides several examples. Starting with the built-in script available at {{ic|/usr/share/mediatomb/js/import.js}}:<br />
<br />
$ cp /usr/share/mediatomb/js/import.js /var/lib/mediatomb/.mediatomb/<br />
<br />
... and edit {{ic|/var/lib/mediatomb/.mediatomb/import.js}} as desired. To utilize the customized script, users must set {{Ic|<nowiki><virtual-layout type="js"></nowiki>}} and specify the script's location.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<virtual-layout type="js"><br />
<import-script>/var/lib/mediatomb/.mediatomb/import.js</import-script><br />
</virtual-layout><br />
<br />
...<br />
</nowiki>}}<br />
<br />
You may have to specify an interface before MediaTomb will be recognized:<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|<nowiki><br />
<server><br />
...<br />
<interface>eth0</interface><br />
...<br />
</server><br />
</nowiki>}}<br />
<br />
... replacing eth0 with the interface you connect on.<br />
<br />
After configuring MediaTomb to your liking, restart the server by running<br />
<br />
# systemctl restart mediatomb<br />
<br />
<br />
== Samsung TV Support ==<br />
For Samsung TV support users should install {{AUR|mediatomb-samsung-tv}} from the [[AUR]], which it's the same as the {{AUR|mediatomb}} package with a few more patches. Note that the TV must have [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] support. Also the server and the TV should be connected to the same network.<br />
<br />
The following note assume MediaTomb is running as a system-wide daemon. For a per-user install, the locations of the configuration file will be different (see above). <br />
<br />
Some models require changes in config.xml. Users should edit the {{Ic|<nowiki><custom-http-headers></nowiki>}} section and add two entries in the {{Ic|<nowiki><mappings></nowiki>}} section for better compatibility.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<custom-http-headers><br />
<add header="transferMode.dlna.org: Streaming"/><br />
<add header="contentFeatures.dlna.org: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=017000 00000000000000000000000000"/><br />
</custom-http-headers><br />
<br />
...<br />
<br />
<map from="avi" to="video/mpeg"/><br />
<map from="mkv" to="video/mpeg"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
== Systemd Integration ==<br />
<br />
The mediatomb package comes with two [[systemd]] service files: mediatomb.service and mediatomb-mariadb.service. They run as 'mediatomb' user, which was created on install, as it isn't secure to run them as root.<br />
<br />
Choose which one you want to use, based on whether you want mediatomb to wait for mariadb to be up and running first or not. I.e. if you use a mariadb backend use mediatomb-mariadb.service, and use mediatomb.service otherwise.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Mediatomb doesn't provide content even though it is added in the webfrontend ===<br />
Be aware of the fact that the user Mediatomb runs under, has to have read rights on the files that are added to be able to provide them. <br />
<br />
So if Mediatomb runs under the user 'mediatomb' the (video-)files either have to be owned by the user 'mediatomb' and need to be readable or the files and the user 'mediatomb' have to belong to the same group with the file being readable ('mediatomb' has to be in the group to which the file belongs (the file then needs the read rights for the group to be set)).</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Gerbera&diff=345515Gerbera2014-11-21T10:52:09Z<p>Kopfweh: Minor Additions; Added possible Troubleshooting</p>
<hr />
<div>[[Category:Streaming]]<br />
{{Related articles start}}<br />
{{Related|Streaming media}}<br />
{{Related articles end}}<br />
<br />
From [http://mediatomb.cc/ MediaTomb - Free UPnP MediaServer]:<br />
<br />
:''MediaTomb is an open source (GPL) UPnP MediaServer with a nice web user interface, it allows you to stream your digital media through your home network and listen to/watch it on a variety of UPnP compatible devices.''<br />
<br />
MediaTomb enables users to stream digital media to UPnP compatible devices like the PlayStation 3 (the Xbox 360 is not yet supported). Several alternatives exist, such as [http://sourceforge.net/projects/fuppes FUPPES], [http://code.google.com/p/ps3mediaserver/ ps3mediaserver], and [[uShare]]. One of MediaTomb's distinguishing features is the ability to customize the server layout based on extracted metadata (scriptable virtual containers); MediaTomb is highly flexible.<br />
<br />
== Installation ==<br />
<br />
MediaTomb is available in the [[AUR]] via {{AUR|mediatomb}}.<br />
<br />
The latest development version is also available in the [[AUR]] via {{AUR|mediatomb-git}}.<br />
<br />
Mediatomb can use its own database, or your local [[MariaDB]] server. For more information about the [[MariaDB]] integration visit the [http://mediatomb.cc/pages/documentation#id2855459 Documentation].<br />
<br />
== Configuration ==<br />
<br />
The default settings may be sufficient for many users, though changes are required for PlayStation 3 support. MediaTomb may be configured and run per-user or as a system-wide daemon. Following installation, either run<br />
<br />
$ mediatomb<br />
<br />
to start MediaTomb as the current user and generate a default configuration in {{ic|~/.mediatomb/config.xml}}, or<br />
<br />
# systemctl start mediatomb<br />
<br />
to start the MediaTomb daemon and generate a default configuration in {{ic|/var/lib/mediatomb/.mediatomb/config.xml}}.<br />
<br />
If you want to use the [[MariaDB]] database backend, you can alternatively run<br />
<br />
# systemctl start mediatomb-mariadb<br />
<br />
which will ensure that [[MariaDB]] is up and running before MediaTomb is.<br />
<br />
<br />
<br />
== Usage ==<br />
<br />
The daemon listens on port 50500 by default. To access the web interface and begin importing media, navigate to http://127.0.0.1:50500/ in your favorite browser (JavaScript required).<br />
<br />
If running per-user instances of MediaTomb, the default port is 49152. However, it is possible that the port will change upon server restart. The URL for the web interface is output during startup. Users may also specify the port manually:<br />
<br />
$ mediatomb -p 50500<br />
<br />
<br />
== Hiding full paths from media players ==<br />
<br />
By default, full directory paths will be shown on devices when they are browsing through folders.<br />
<br />
For example, if you add the directory /media/my_media/video_data/videos/movies, anyone connecting will have to navigate to the 'movies' directory from the root.<br />
<br />
To hide all of that and only show the directory added, you can change the import script.<br />
<br />
For example, this script will automatically truncate the whole directory structure specified in the variable video_root. Any directories added directly under the video root path will show up on UPnP devices starting from the that folder rather than /.<br />
<br />
function addVideo(obj)<br />
{<br />
var video_root = "/media/main_core/Server_Core_Folder/FTP_Services/Media/";<br />
<br />
var absolute_path = obj.location;<br />
<br />
var relative_path = absolute_path;<br />
<br />
if(absolute_path.indexOf(video_root) == 0)<br />
relative_path = absolute_path.replace(video_root, "")<br />
<br />
var chain = new Array();<br />
<br />
var pathSplit = relative_path.split("/");<br />
<br />
for(var i = 0; i < pathSplit.length - 1; i++) <br />
chain.push(pathSplit[i]);<br />
<br />
addCdsObject(obj, createContainerChain(chain));<br />
}<br />
<br />
To also hide the default PC Directory folder from UPnP device directory listings, add the following directly under the server node of your config.xml file.<br />
<br />
<pc-directory upnp-hide="yes"/><br />
<br />
<br />
== Playstation 3 Support ==<br />
<br />
The following notes assume MediaTomb is running as a system-wide daemon. For a per-user install, the locations of the configuration file will be different (see above).<br />
<br />
For PlayStation 3 support, users must set {{Ic|<nowiki><protocolInfo extend="yes"/></nowiki>}}. An "avi" mimetype mapping should also be uncommented for DivX support.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<protocolInfo extend="yes"/><br />
<br />
...<br />
<br />
<map from="avi" to="video/divx"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
When importing media to the database, MediaTomb will create a virtual container layout as defined by the {{Ic|<nowiki><virtual-layout type="..."></nowiki>}} option. That is, media will be organized according to metadata (album, artist, etc.) through creation of virtual database objects. If your media is already organized on the file system, you may disable this feature to significantly improve import performance:<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<virtual-layout type="disabled"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
Users may customize the import script to fine-tune the virtual layout. The [http://mediatomb.cc/dokuwiki/scripting:scripting Scripting] section of the MediaTomb wiki provides several examples. Starting with the built-in script available at {{ic|/usr/share/mediatomb/js/import.js}}:<br />
<br />
$ cp /usr/share/mediatomb/js/import.js /var/lib/mediatomb/.mediatomb/<br />
<br />
... and edit {{ic|/var/lib/mediatomb/.mediatomb/import.js}} as desired. To utilize the customized script, users must set {{Ic|<nowiki><virtual-layout type="js"></nowiki>}} and specify the script's location.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<virtual-layout type="js"><br />
<import-script>/var/lib/mediatomb/.mediatomb/import.js</import-script><br />
</virtual-layout><br />
<br />
...<br />
</nowiki>}}<br />
<br />
You may have to specify an interface before MediaTomb will be recognized:<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|<nowiki><br />
<server><br />
...<br />
<interface>eth0</interface><br />
...<br />
</server><br />
</nowiki>}}<br />
<br />
... replacing eth0 with the interface you connect on.<br />
<br />
After configuring MediaTomb to your liking, restart the server by running<br />
<br />
# systemctl restart mediatomb<br />
<br />
<br />
== Samsung TV Support ==<br />
For Samsung TV support users should install {{AUR|mediatomb-samsung-tv}} from the [[AUR]], which it's the same as the {{AUR|mediatomb}} package with a few more patches. Note that the TV must have [http://en.wikipedia.org/wiki/Digital_Living_Network_Alliance DLNA] support. Also the server and the TV should be connected to the same network.<br />
<br />
The following note assume MediaTomb is running as a system-wide daemon. For a per-user install, the locations of the configuration file will be different (see above). <br />
<br />
Some models require changes in config.xml. Users should edit the {{Ic|<nowiki><custom-http-headers></nowiki>}} section and add two entries in the {{Ic|<nowiki><mappings></nowiki>}} section for better compatibility.<br />
<br />
{{hc|/var/lib/mediatomb/.mediatomb/config.xml<br />
|2=<nowiki><br />
...<br />
<br />
<custom-http-headers><br />
<add header="transferMode.dlna.org: Streaming"/><br />
<add header="contentFeatures.dlna.org: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=017000 00000000000000000000000000"/><br />
</custom-http-headers><br />
<br />
...<br />
<br />
<map from="avi" to="video/mpeg"/><br />
<map from="mkv" to="video/mpeg"/><br />
<br />
...<br />
</nowiki>}}<br />
<br />
== Systemd Integration ==<br />
<br />
The mediatomb package comes with two [[systemd]] service files: mediatomb.service and mediatomb-mariadb.service. They run as 'mediatomb' user, which was created on install, as it isn't secure to run them as root.<br />
<br />
Choose which one you want to use, based on whether you want mediatomb to wait for mariadb to be up and running first or not. I.e. if you use a mariadb backend use mediatomb-mariadb.service, and use mediatomb.service otherwise.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Mediatomb doesn't provide content even though it is added in the webfrontend ===<br />
Be aware of the fact that the user Mediatomb runs under, has to have read rights on the files that are added to be able to provide them. <br />
So if Mediatomb runs under the user 'mediatomb' the (video-)files either have to be owned by 'mediatomb' and be readable, the files have to belong to the group and be readable or 'mediatomb' has to be in the group to which the file belongs (again with read rights for the group).</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Pacman/Pacnew_and_Pacsave&diff=271460Pacman/Pacnew and Pacsave2013-08-17T16:12:21Z<p>Kopfweh: /* Managing .pacnew Files */</p>
<hr />
<div>[[Category:Package management]]<br />
[[cs:Pacnew and Pacsave Files]]<br />
[[de:Pacnew- und Pacsave-Dateien]]<br />
[[es:Pacnew and Pacsave Files]]<br />
[[fr:Gestion des fichiers de configurations]]<br />
[[it:Pacnew and Pacsave Files]]<br />
== Getting Started ==<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. <br />
<br />
Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
A {{ic|.pacnew}} file may be created during a package upgrade ({{Ic|pacman -Syu}}, {{Ic|pacman -Su}} or {{Ic|pacman -U}}) to avoid overwriting a file which already exists and was previously modified by the user. When this happens a message like the following will appear in the output of pacman:<br />
<br />
warning: /etc/pam.d/usermod installed as /etc/pam.d/usermod.pacnew<br />
<br />
A {{ic|.pacsave}} file may be created during a package removal ({{Ic|pacman -R}}), or by a package upgrade (the package must be removed first). When the pacman database has record that a certain file owned by the package should be backed up it will create a {{ic|.pacsave}} file. When this happens pacman outputs a message like the following:<br />
<br />
warning: /etc/pam.d/usermod saved as /etc/pam.d/usermod.pacsave<br />
<br />
These files require manual intervention from the user and it is good practice to handle them right after every package upgrade or removal. If left unhandled, improper configurations can result in improper function of the software, or the software being unable to run altogether.<br />
<br />
== Package backup files ==<br />
<br />
A package's {{ic|PKGBUILD}} file specifies which files should be preserved or backed up when the package is upgraded or removed. For example, the {{ic|PKGBUILD}} for {{ic|pulseaudio}} contains the following line:<br />
<br />
backup=('etc/pulse/client.conf' 'etc/pulse/daemon.conf' 'etc/pulse/default.pa')<br />
<br />
== Types Explained ==<br />
<br />
The different types of *.pac* files.<br />
<br />
===.pacnew===<br />
<br />
For each {{ic|backup}} file in a package being upgraded, pacman cross-compares three [[wikipedia:Md5sum|md5sums]] generated from the file's contents: one sum for the version originally installed by the package, one for the version currently in the filesystem, and one for the version in the new package. If the version of the file currently in the filesystem has been modified from the version originally installed by the package, pacman cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, pacman saves the new version with a {{ic|.pacnew}} extension and leaves the modified version untouched.<br />
<br />
Going into further detail, the 3-way MD5 sum comparison results in one of the following outcomes:<br />
<br />
; original = ''X'', current = ''X'', new = ''X'' : All three versions of the file have identical contents, so overwriting is not a problem. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''X'', new = ''Y'' : The current version's contents are identical to the original's, but the new version is different. Since the user has not modified the current version and the new version may contain improvements or bugfixes, overwrite the current version with the new version and do not notify the user. This is the only auto-merging of new changes that pacman is capable of performing.<br />
<br />
; original = ''X'', current = ''Y'', new = ''X'' : The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.<br />
<br />
; original = ''X'', current = ''Y'', new = ''Y'' : The new version is identical to the current version. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''Y'', new = ''Z'' : All three versions are different, so leave the current version in place, install the new version with a {{ic|.pacnew}} extension and warn the user about the new version. The user will be expected to manually merge any changes necessary from the new version into the current version.<br />
<br />
===.pacsave===<br />
<br />
If the user has modified one of the files specified in {{ic|backup}} then that file will be renamed with a {{ic|.pacsave}} extension and will remain in the filesystem after the rest of the package is removed.<br />
<br />
{{Box Note | Use of the {{ic|-n}} option with {{ic|pacman -R}} will result in complete removal of ''all'' files in the specified package, therefore no {{ic|.pacsave}} files will be created.}}<br />
<br />
===.pacorig===<br />
<br />
When a file (usually a configuration found in {{ic|/etc}}) is encountered during package installation or upgrade that does not belong to any installed package but is listed in {{ic|backup}} for the package in the current operation, it will be saved with a {{ic|'''.pacorig'''}} extension and replaced with the version of the file from the package. Usually this happens when a configuration file has been moved from one package to another. If such a file were not listed in {{ic|backup}}, pacman would abort with a file conflict error.<br />
<br />
{{Box Note | Because {{ic|.pacorig}} files tend to be created for special circumstances, there is no universal method for handling them. It may be helpful to consult the [https://www.archlinux.org/news/ Arch News] for handling instructions if it is a known case.}}<br />
<br />
== Locating .pac* Files==<br />
<br />
Arch Linux does not provide official utilities for {{ic|.pacnew}} files. You'll need to maintain these yourself; a few tools are presented in the next section. To do this manually, first you will need to locate them. When upgrading or removing a large number of packages, updated *.pac* files may be missed. To discover whether any {{ic|*.pac*}} files have been installed:<br />
<br />
To just search where most global configurations are stored:<br />
<br />
$ find /etc -regextype posix-extended -regex ".+\.pac(new|save|orig)" 2> /dev/null<br />
<br />
or the entire disk:<br />
<br />
$ find / -regextype posix-extended -regex ".+\.pac(new|save|orig)" 2> /dev/null<br />
<br />
Or use [[locate]] if you have installed it. First re-index the database:<br />
<br />
# updatedb<br />
<br />
Then:<br />
<br />
$ locate -e --regex "\.pac(new|orig|save)$"<br />
<br />
Or use pacman's log to find them:<br />
<br />
$ egrep "pac(new|orig|save)" /var/log/pacman.log<br />
<br />
Note that the log does not keep track of which files are currently in the filesystem nor of which files have already been removed.<br />
<br />
== Managing .pacnew Files==<br />
There are various tools to help resolve .pacnew and .pacsave file issues. The standard diff utility (alternatively, colordiff) provides an easy way to compare the files. Finally, the [https://github.com/pbrisbin/scripts/blob/master/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
Once all existing {{ic|.pacnew}} files have been located, the user may handle them manually using common merge tools such as [[Vim#Merging_files_.28vimdiff.29|vimdiff]], ediff (part of [[Emacs|emacs]]), {{Pkg|meld}} (a GNOME GUI tool), sdiff (part of {{Pkg|diffutils}}), or {{Pkg|Kompare}} (a KDE GUI tool), then deleting the {{ic|.pacnew}} files afterwards.<br />
<br />
A few third-party utilities providing various levels of automation for these tasks are available from the [[AUR_User_Guidelines#.5Bcommunity.5D|community repository]] and the [[Arch User Repository|AUR]].<br />
<br />
*pacdiff - A minimal CLI script from {{Pkg|pacman}} package. It will search all the pacnew and pacsave files and asking for action on them.<br />
*{{AUR|pacmerge-git}} - CLI interactive merge program<br />
*[[Vim#Merging_files_.28vimdiff.29|Vimdiff]] - a type of Vim specially designed for merging files<br />
*[[Dotpac]] - Basic interactive script with ncurses-based text interface and helpful walkthrough. No merging or auto-merging features.<br />
*pacdiffviewer - Full-featured interactive CLI script with auto-merging capability. Part of the {{AUR|yaourt}} package.<br />
*{{AUR|diffpac}} - Standalone pacdiffviewer replacement<br />
*[[Yaourt]] - A package manager that supports the AUR repository. Use {{ic|yaourt -C}} to compare, replace and merge configuration files..<br />
*{{AUR|etc-update}} - Arch port of [http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_chap2 Gentoo's etc-update] utility, providing a simple CLI to view changes, interactively edit and merge changes, and automatically merge trivial changes (e.g. comments.) Unlike some others above, this uses your preferred text editor rather than forcing you to learn a new one.<br />
*{{Pkg|meld}} - Easy-to-use program with a graphical user interface on which two (or more) files can be compared and edited side-by-side. It highlights the differences between the opened files in color.<br />
*{{AUR|pacnews-git}} is a simple script aimed at finding all {{ic|.pacnew}} files, then editing with {{ic|vimdiff}}. It differs from the below script using {{ic|meld}}.<br />
<br />
<br />
=== Using Meld to Update Differences ===<br />
<br />
Using meld in a loop can be used to update configuration files. This script will loop through the files one by one then prompt to delete the {{Ic|.pacnew}} file. <br />
<br />
{{hc|pacnew|<pre>#!/bin/bash<br />
# Merge new *.pacnew configuration files with their originals<br />
<br />
pacnew=$(find /etc -type f -name "*.pacnew")<br />
<br />
# Check if any .pacnew configurations are found<br />
if [[ -z "$pacnew" ]]; then<br />
echo " No configurations to update"<br />
fi<br />
<br />
for config in $pacnew; do<br />
# Diff original and new configuration to merge<br />
gksudo meld ${config%\.*} $config &<br />
wait<br />
# Remove .pacnew file?<br />
while true; do<br />
read -p " Delete \""$config"\"? (Y/n): " Yn<br />
case $Yn in<br />
[Yy]* ) sudo rm "$config" && \<br />
echo " Deleted \""$config"\"."<br />
break ;;<br />
[Nn]* ) break ;;<br />
* ) echo " Answer (Y)es or (n)o." ;;<br />
esac<br />
done<br />
done</pre>}}<br />
<br />
The above script uses [[GNOME]]'s {{Ic|gksudo}} for graphical sudo permissions. Use {{Ic|kdesu}} for [[KDE]].<br />
<br />
== Resources ==<br />
<br />
*Arch Linux Forums: [https://bbs.archlinux.org/viewtopic.php?id=53532 Dealing With .pacnew Files]</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Pacman/Pacnew_and_Pacsave&diff=271459Pacman/Pacnew and Pacsave2013-08-17T16:10:36Z<p>Kopfweh: /* Managing .pacnew Files */</p>
<hr />
<div>[[Category:Package management]]<br />
[[cs:Pacnew and Pacsave Files]]<br />
[[de:Pacnew- und Pacsave-Dateien]]<br />
[[es:Pacnew and Pacsave Files]]<br />
[[fr:Gestion des fichiers de configurations]]<br />
[[it:Pacnew and Pacsave Files]]<br />
== Getting Started ==<br />
When pacman removes a package that has a configuration file, it normally creates a backup copy of that config file and appends .pacsave to the name of the file. <br />
<br />
Likewise, when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file. Occasionally, under special circumstances, a .pacorig file is created. Pacman provides notice when these files are written.<br />
<br />
A {{ic|.pacnew}} file may be created during a package upgrade ({{Ic|pacman -Syu}}, {{Ic|pacman -Su}} or {{Ic|pacman -U}}) to avoid overwriting a file which already exists and was previously modified by the user. When this happens a message like the following will appear in the output of pacman:<br />
<br />
warning: /etc/pam.d/usermod installed as /etc/pam.d/usermod.pacnew<br />
<br />
A {{ic|.pacsave}} file may be created during a package removal ({{Ic|pacman -R}}), or by a package upgrade (the package must be removed first). When the pacman database has record that a certain file owned by the package should be backed up it will create a {{ic|.pacsave}} file. When this happens pacman outputs a message like the following:<br />
<br />
warning: /etc/pam.d/usermod saved as /etc/pam.d/usermod.pacsave<br />
<br />
These files require manual intervention from the user and it is good practice to handle them right after every package upgrade or removal. If left unhandled, improper configurations can result in improper function of the software, or the software being unable to run altogether.<br />
<br />
== Package backup files ==<br />
<br />
A package's {{ic|PKGBUILD}} file specifies which files should be preserved or backed up when the package is upgraded or removed. For example, the {{ic|PKGBUILD}} for {{ic|pulseaudio}} contains the following line:<br />
<br />
backup=('etc/pulse/client.conf' 'etc/pulse/daemon.conf' 'etc/pulse/default.pa')<br />
<br />
== Types Explained ==<br />
<br />
The different types of *.pac* files.<br />
<br />
===.pacnew===<br />
<br />
For each {{ic|backup}} file in a package being upgraded, pacman cross-compares three [[wikipedia:Md5sum|md5sums]] generated from the file's contents: one sum for the version originally installed by the package, one for the version currently in the filesystem, and one for the version in the new package. If the version of the file currently in the filesystem has been modified from the version originally installed by the package, pacman cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, pacman saves the new version with a {{ic|.pacnew}} extension and leaves the modified version untouched.<br />
<br />
Going into further detail, the 3-way MD5 sum comparison results in one of the following outcomes:<br />
<br />
; original = ''X'', current = ''X'', new = ''X'' : All three versions of the file have identical contents, so overwriting is not a problem. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''X'', new = ''Y'' : The current version's contents are identical to the original's, but the new version is different. Since the user has not modified the current version and the new version may contain improvements or bugfixes, overwrite the current version with the new version and do not notify the user. This is the only auto-merging of new changes that pacman is capable of performing.<br />
<br />
; original = ''X'', current = ''Y'', new = ''X'' : The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.<br />
<br />
; original = ''X'', current = ''Y'', new = ''Y'' : The new version is identical to the current version. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''Y'', new = ''Z'' : All three versions are different, so leave the current version in place, install the new version with a {{ic|.pacnew}} extension and warn the user about the new version. The user will be expected to manually merge any changes necessary from the new version into the current version.<br />
<br />
===.pacsave===<br />
<br />
If the user has modified one of the files specified in {{ic|backup}} then that file will be renamed with a {{ic|.pacsave}} extension and will remain in the filesystem after the rest of the package is removed.<br />
<br />
{{Box Note | Use of the {{ic|-n}} option with {{ic|pacman -R}} will result in complete removal of ''all'' files in the specified package, therefore no {{ic|.pacsave}} files will be created.}}<br />
<br />
===.pacorig===<br />
<br />
When a file (usually a configuration found in {{ic|/etc}}) is encountered during package installation or upgrade that does not belong to any installed package but is listed in {{ic|backup}} for the package in the current operation, it will be saved with a {{ic|'''.pacorig'''}} extension and replaced with the version of the file from the package. Usually this happens when a configuration file has been moved from one package to another. If such a file were not listed in {{ic|backup}}, pacman would abort with a file conflict error.<br />
<br />
{{Box Note | Because {{ic|.pacorig}} files tend to be created for special circumstances, there is no universal method for handling them. It may be helpful to consult the [https://www.archlinux.org/news/ Arch News] for handling instructions if it is a known case.}}<br />
<br />
== Locating .pac* Files==<br />
<br />
Arch Linux does not provide official utilities for {{ic|.pacnew}} files. You'll need to maintain these yourself; a few tools are presented in the next section. To do this manually, first you will need to locate them. When upgrading or removing a large number of packages, updated *.pac* files may be missed. To discover whether any {{ic|*.pac*}} files have been installed:<br />
<br />
To just search where most global configurations are stored:<br />
<br />
$ find /etc -regextype posix-extended -regex ".+\.pac(new|save|orig)" 2> /dev/null<br />
<br />
or the entire disk:<br />
<br />
$ find / -regextype posix-extended -regex ".+\.pac(new|save|orig)" 2> /dev/null<br />
<br />
Or use [[locate]] if you have installed it. First re-index the database:<br />
<br />
# updatedb<br />
<br />
Then:<br />
<br />
$ locate -e --regex "\.pac(new|orig|save)$"<br />
<br />
Or use pacman's log to find them:<br />
<br />
$ egrep "pac(new|orig|save)" /var/log/pacman.log<br />
<br />
Note that the log does not keep track of which files are currently in the filesystem nor of which files have already been removed.<br />
<br />
== Managing .pacnew Files==<br />
There are various tools to help resolve .pacnew and .pacsave file issues. The standard diff utility (alternatively, colordiff) provides an easy way to compare the files. Finally, the [https://github.com/pbrisbin/scripts/blob/master/pacnews pacnews bash script] provides similar functionality. Both pacdiff and pacnews use vimdiff to compare and edit .pacnew and .pacsave files.<br />
<br />
Once all existing {{ic|.pacnew}} files have been located, the user may handle them manually using common merge tools such as [[Vim#Merging_files_.28vimdiff.29|vimdiff]], ediff (part of [[Emacs|emacs]]), {{Pkg|meld}} (a GNOME GUI tool), sdiff (part of {{Pkg|diffutils}}), or {{Pkg|Kompare}} (a KDE GUI tool), then deleting the {{ic|.pacnew}} files afterwards.<br />
<br />
A few third-party utilities providing various levels of automation for these tasks are available from the [[AUR_User_Guidelines#.5Bcommunity.5D|community repository]] and the [[Arch User Repository|AUR]].<br />
<br />
*pacdiff - A minimal CLI script from {{Pkg|pacman}} package. It will search all the pacnew and pacsave files and asking for action on them.<br />
*{{AUR|pacmerge-git}} - CLI interactive merge program<br />
*[[Vim#Merging_files_.28vimdiff.29|Vimdiff]] - a type of Vim specially designed for merging files<br />
*[[Dotpac]] - Basic interactive script with ncurses-based text interface and helpful walkthrough. No merging or auto-merging features.<br />
*pacdiffviewer - Full-featured interactive CLI script with auto-merging capability. Part of the {{AUR|yaourt}} package.<br />
*{{AUR|diffpac}} - Standalone pacdiffviewer replacement<br />
*[[Yaourt]] - A package manager that supports the AUR repository. Use {{ic|yaourt -C}} to compare, replace and merge configuration files..<br />
*{{AUR|etc-update}} - Arch port of [http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_chap2 Gentoo's etc-update] utility, providing a simple CLI to view changes, interactively edit and merge changes, and automatically merge trivial changes (e.g. comments.) Unlike some others above, this uses your preferred text editor rather than forcing you to learn a new one.<br />
*{{AUR|pacnews-git}} is a simple script aimed at finding all {{ic|.pacnew}} files, then editing with {{ic|vimdiff}}. It differs from the below script using {{ic|meld}}.<br />
*{{Pkg|meld}} - Easy-to-use program with a graphical user interface on which two (or more) files can be compared and edited side-by-side. It highlights the differences between the opened files in color.<br />
<br />
=== Using Meld to Update Differences ===<br />
<br />
Using meld in a loop can be used to update configuration files. This script will loop through the files one by one then prompt to delete the {{Ic|.pacnew}} file. <br />
<br />
{{hc|pacnew|<pre>#!/bin/bash<br />
# Merge new *.pacnew configuration files with their originals<br />
<br />
pacnew=$(find /etc -type f -name "*.pacnew")<br />
<br />
# Check if any .pacnew configurations are found<br />
if [[ -z "$pacnew" ]]; then<br />
echo " No configurations to update"<br />
fi<br />
<br />
for config in $pacnew; do<br />
# Diff original and new configuration to merge<br />
gksudo meld ${config%\.*} $config &<br />
wait<br />
# Remove .pacnew file?<br />
while true; do<br />
read -p " Delete \""$config"\"? (Y/n): " Yn<br />
case $Yn in<br />
[Yy]* ) sudo rm "$config" && \<br />
echo " Deleted \""$config"\"."<br />
break ;;<br />
[Nn]* ) break ;;<br />
* ) echo " Answer (Y)es or (n)o." ;;<br />
esac<br />
done<br />
done</pre>}}<br />
<br />
The above script uses [[GNOME]]'s {{Ic|gksudo}} for graphical sudo permissions. Use {{Ic|kdesu}} for [[KDE]].<br />
<br />
== Resources ==<br />
<br />
*Arch Linux Forums: [https://bbs.archlinux.org/viewtopic.php?id=53532 Dealing With .pacnew Files]</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Systemd&diff=226531Systemd2012-10-02T14:42:17Z<p>Kopfweh: /* Using display manager */ added whitespace</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Systemd/Services}}<br />
{{Article summary wiki|Init to systemd cheatsheet}}<br />
{{Article summary wiki|udev}} - systemd and udev have been merged upstream.<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
''"'''systemd''' is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."''<br />
<br />
{{Note|For a detailed explanation as to why Arch is switching to systemd, see: [https://bbs.archlinux.org/viewtopic.php?pid&#61;1149530#p1149530 this forum post].}}<br />
<br />
See also the [[Wikipedia:Systemd|Wikipedia article]].<br />
<br />
== Things to consider before you switch ==<br />
<br />
* It is highly recommended to switch to the new '''initscripts''' configuration system described in the [[rc.conf|rc.conf article]]. Once you have this configuration established, you will have done most of the work needed to make the switch to systemd.<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about systemd.<br />
* Note the fact that systemd has a '''journal''' system that replaces '''syslog''', although the two can co-exist. See the [[#Journald_in_conjunction_with_a_classic_syslog_daemon|section on the journal]] below.<br />
* Do not worry about systemd's plans to replace the functionality of '''cron''', '''acpid''', or '''xinetd'''. These are not things you need to worry about just yet. For now, you can continue to use your traditional daemons for these tasks.<br />
<br />
== Installation ==<br />
systemd can be installed side-by-side with the regular Arch Linux {{pkg|initscripts}} package, and they can be toggled by adding/removing the {{Ic|1=init=/bin/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A pure systemd installation ===<br />
<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/bin/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Create [[#Native systemd configuration files|systemd configuration files]].<br />
# [[#Using_Units|Enable daemons]] formerly listed in {{ic|/etc/rc.conf}} with {{ic|systemctl enable ''daemonname.'''service''' ''}}. For a translation of the daemons from {{ic|/etc/rc.conf}} to systemd services, see: [[Daemon#List_of_Daemons|List of Daemons]] and [[Systemd/Services|Services]]<br />
# Reboot. Your system should now initialize with systemd. If you are satisfied, remove the {{ic|1=init=...}} entry.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
<br />
=== A mixed systemd installation ===<br />
<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]]<br />
# Add {{ic|1=init=/bin/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# We recommend that you use [[#Native systemd configuration files|native systemd configuration files]] instead of Arch's classic configuration files. You can still use {{ic|/etc/rc.conf}} to configure a few variables if the native configuration files do not exist, but support will be dropped in the future.<br />
# If you want to keep using syslog log files alongside the systemd journal, follow the instructions described in the [[#Journald_in_conjunction_with_a_classic_syslog_daemon|section on the journal]], below.<br />
<br />
=== Supplementary information ===<br />
{{Note|1=In a pure systemd installation, installing {{pkg|systemd-sysvcompat}} replaces {{pkg|sysvinit}} and creates symlinks to halt, reboot, etc.}}<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you should remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
{{Warning|{{ic|/usr}} must be mounted and available at bootup (this is not particular to systemd). If your {{ic|/usr}} is on a separate partition, you will need to make accommodations to mount it from the initramfs and unmount it from a pivoted root on shutdown. See [[Mkinitcpio#/usr_as_a_separate_partition|the mkinitcpio wiki page]] and [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken freedesktop.org#separate-usr-is-broken].}}<br />
<br />
== Native systemd configuration files ==<br />
{{Note|You may need to create these files.}}<br />
{{Pkg|systemd}} will use {{ic|/etc/rc.conf}} if these files are absent. Note this is temporary and not a long-term solution. It is strongly advised to use the systemd configuration files on any system.<br />
=== Hostname ===<br />
{{hc|/etc/hostname|myhostname}}<br />
<br />
=== Console and keymap ===<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
{{hc|/etc/vconsole.conf|<nowiki><br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni</nowiki>}}<br />
<br />
For more info see [[Fonts#Console_fonts|Console fonts]] and [[KEYMAP#Keyboard_layouts|Keymap]].<br />
<br />
{{Tip|To use the kernel compiled-in font and keymap rather than the systemd-default ones use<br />
{{hc|/etc/vconsole.conf|<nowiki><br />
KEYMAP=<br />
FONT=<br />
</nowiki>}}<br />
This might be the default in the future.<br />
}}<br />
<br />
=== Locale ===<br />
Read {{ic|man locale.conf}} for more options:<br />
{{hc|/etc/locale.conf|<nowiki><br />
LANG=en_US.UTF-8<br />
LC_COLLATE=C</nowiki>}}<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
Read {{ic|man 5 localtime}} for more options.<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
or, if you want to use a relative symlink:<br />
# ln -sf ../usr/share/zoneinfo/America/Chicago /etc/localtime<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
Systemd will use UTC for the hardware clock by default and this is recommended. Dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). Recent kernels set the system time from the RTC directly on boot without using {{ic|hwclock}}, the kernel will always assume that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is possibly the reason for certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
The reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC_in_Windows|registry fix]]. If you run into issues on dual boot with Windows, you can set the hardware clock to local time. Contrary to popular belief, systemd supports this:<br />
<br />
{{hc|/etc/adjtime|<br />
0.0 0.0 0.0<br />
0<br />
LOCAL}}<br />
<br />
The other parameters are still needed but are ignored by systemd.<br />
<br />
It is generally advised to have a [[NTP|Network Time Protocol daemon]] running to keep the hardware clock synchronized with the system time.<br />
<br />
=== Kernel modules loaded during boot ===<br />
systemd uses {{ic|/etc/modules-load.d/}} to configure kernel modules to load during boot in a static list. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is {{ic|#}} or {{ic|;}} are ignored. Example:<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<nowiki><br />
# Load virtio-net.ko at boot<br />
virtio-net</nowiki>}}<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
Module blacklisting works the same way as with {{Pkg|initscripts}} since it is actually handled by {{Pkg|kmod}}. See [[Kernel_modules#Blacklisting|Module Blacklisting]] for details.<br />
<br />
=== Temporary files ===<br />
Systemd-tmpfiles uses the configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/<program>.conf}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/var/run/samba}} to exist and to have the correct permissions. The corresponding tmpfile looks like this:<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root<br />
}}<br />
<br />
However, tmpfiles may also be used to write values into certain files on boot. For example, if you use {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE<br />
}}<br />
The tmpfiles method is recommended in this case since systemd doesn't actually support {{ic|/etc/rc.local}}.<br />
<br />
See {{ic|man tmpfiles.d}} for details.<br />
<br />
=== Remote filesystem mounts ===<br />
systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
You may however want to use [[#Automount|Automount]] for remote filesystem mounts to mount them only upon access. Furthermore you can use the {{ic|1=x-systemd.device-timeout=#}} option in {{ic|/etc/fstab}} to specify a timeout in case the network resource is not available.<br />
<br />
See {{ic|man systemd.mount}} for details.<br />
<br />
=== ACPI Power Management with systemd ===<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
* {{ic|HandlePowerKey}}: specifies which action is invoked when the power key is pressed<br />
* {{ic|HandleSuspendKey}}: specifies which action is invoked when the suspend key is pressed<br />
* {{ic|HandleHibernateKey}}: specifies which action is invoked when the hibernate key is pressed<br />
* {{ic|HandleLidSwitch}}: specifies which action is invoked when the lid is closed<br />
The specified action can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.<br />
<br />
If these options are not configured, systemd will use it's defaults: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
On systems which run no graphical setup or only a simple window manager like [[i3]] or [[awesome]], this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
{{Note|If you want to continue using the acpid daemon to handle these events, you will need to set these options to {{ic|ignore}} or they will try to be handled twice.}}<br />
==== "Inhibited" ACPI events ====<br />
In the current version of systemd, the {{ic|Handle}} options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If you want systemd to always handle these events, you can tell it to ignore the inhibited signals with the following options in {{ic|/etc/systemd/logind.conf}}:<br />
*{{ic|PowerKeyIgnoreInhibited}}<br />
*{{ic|SuspendKeyIgnoreInhibited}}<br />
*{{ic|HibernateKeyIgnoreInhibited}}<br />
*{{ic|LidSwitchIgnoreInhibited}}<br />
All of these default to no, except {{ic|LidSwitchIgnoreInhibited}}.<br />
{{Warning|If you want your desktop environment's power manager to handle the LidSwitch event you MUST set {{ic|1=LidSwitchIgnoreInhibited=no}}}}<br />
{{Note|Currently, no power managers issue the necessary "inhibited" commands. Until they do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[KDE]], [[GNOME]], [[Xfce]], or others. New versions are on the way that will include this functionality.}}<br />
<br />
=== Sleep hooks ===<br />
<br />
Systemd does not use [[pm-utils]] to put the machine to sleep when using {{ic|systemctl suspend}} or {{ic|systemctl hibernate}}, therefore [[pm-utils]] hooks including any [[Pm-utils#Creating_your_own_hooks|custom hooks]] created will not be run. However, systemd provides a similar mechanism to run custom scripts on these events. Systemd runs all executables in {{ic|/usr/lib/systemd/system-sleep/}} and passes two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: either {{ic|suspend}} or {{ic|hibernate}}, depending on what has been invoked<br />
<br />
In contrast to [[pm-utils]], systemd will run these scripts in parallel and not one after another.<br />
<br />
The output of your script will be logged by {{ic|systemd-suspend.service}} or {{ic|systemd-hibernate.service}} so you can see its output in the [[Systemd#Systemd Journal|journal]].<br />
<br />
Note that you can also use {{ic|sleep.target}}, {{ic|suspend.target}} or {{ic|hibernate.target}} to hook units into the sleep state logic instead of using scripts.<br />
<br />
See {{ic|man systemd.special}} and {{ic|man systemd-sleep}} for more information.<br />
<br />
==== Example ====<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki><br />
#!/bin/sh<br />
<br />
case "$1" in<br />
pre )<br />
echo going to $2 ...<br />
;;<br />
post )<br />
echo waking up from $2 ...<br />
;;<br />
esac</nowiki>}}<br />
<br />
=== Unit ===<br />
A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd. The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files. See {{ic|man systemd.unit}} for more info.<br />
<br />
== Systemd commands ==<br />
<br />
*{{ic|systemctl}}: used to introspect and control the state of the systemd system and service manager.<br />
*{{ic|systemd-cgls}}: recursively shows the contents of the selected Linux control group hierarchy in a tree<br />
*{{ic|systemadm}}: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd (available via the {{AUR|systemd-ui-git}} package from the [[AUR]]).<br />
<br />
View the man pages for more details. <br />
<br />
{{Tip|You can use all of the following {{ic|systemctl}} commands with the {{ic|-H <user>@<host>}} switch to control a systemd instance on a remote machine. This will use [[SSH]] to connect to the remote systemd instance.}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
{{bc|$ systemctl}}<br />
<br />
or:<br />
<br />
{{bc|$ systemctl list-units}}<br />
<br />
List failed units:<br />
<br />
{{bc|$ systemctl --failed}}<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see list installed unit files by:<br />
{{bc|$ systemctl list-unit-files}}<br />
<br />
=== Using Units ===<br />
<br />
Units can be, for example, services ({{ic|.service}}), mount points ({{ic|.mount}}), devices ({{ic|.device}}) or sockets ({{ic|.socket}}).<br />
When using {{ic|systemctl}}, you generally have to specify the complete name of the unit file, including its suffix, for example {{ic|sshd.socket}}. There are however a few shortforms when specifying the unit in the following {{ic|systemctl}} commands:<br />
* If you don't specify the suffix, systemctl will assume {{ic|.service}}. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are treated equivalent. {{Note|This currently does not work with the commands {{ic|enable}} and {{ic|disable}}.}}<br />
* Mount points will automatically be translated into the appropriate {{ic|.mount}} unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similiar to mount points, devices are automatically translated into the appropriate {{ic|.device}} unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
{{bc|# systemctl start <unit>}}<br />
<br />
Deactivate a unit immediately:<br />
<br />
{{bc|# systemctl stop <unit>}}<br />
<br />
Restart a unit:<br />
<br />
{{bc|# systemctl restart <unit>}}<br />
<br />
Ask a unit to reload its configuration:<br />
<br />
{{bc|# systemctl reload <unit>}}<br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
{{bc|$ systemctl status <unit>}}<br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
{{bc|$ systemctl is-enabled <unit>}}<br />
<br />
Enable a unit to be started on bootup:<br />
<br />
{{bc|# systemctl enable <unit>}}<br />
<br />
{{Note| If services do not have an Install section, it usually means they are called automatically by other services. But if you need to install them manually, use the following command, replacing ''foo'' with the name of the service.<br />
<br />
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}<br />
<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
{{bc|# systemctl disable <unit>}}<br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
{{bc|$ systemctl help <unit>}}<br />
<br />
=== Power Management ===<br />
<br />
If you are in a local {{ic|systemd-logind}} or [[ConsoleKit]] user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password (see also [[#Replacing_ConsoleKit_with_systemd-logind|Replacing ConsoleKit with systemd-logind]]).<br />
<br />
Shut down and reboot the system:<br />
<br />
{{bc|$ systemctl reboot}}<br />
<br />
Shut down and power-off the system:<br />
<br />
{{bc|$ systemctl poweroff}}<br />
<br />
Shut down and halt the system:<br />
<br />
{{bc|$ systemctl halt}}<br />
<br />
Suspend the system:<br />
<br />
{{bc|$ systemctl suspend}}<br />
<br />
Hibernate the system:<br />
<br />
{{bc|$ systemctl hibernate}}<br />
<br />
== Runlevels/targets ==<br />
Runlevels is a legacy concept in systemd. Systemd uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''targets'' are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are systemd ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command. <br />
<br />
=== Get current runlevel/targets ===<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
{{bc|1=# systemctl list-units --type=target}}<br />
<br />
=== Create custom target ===<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd ''target'' as {{ic|/etc/systemd/system/<your target>}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/<your target>.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
{| border="1"<br />
!SysV Runlevel!!Systemd Target!!Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current runlevels ===<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
{{bc|# systemctl isolate graphical.target}}<br />
This will only change the current runlevel, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default runlevel/target to boot into ===<br />
The standard target is {{ic|default.target}}, which is aliased by default to {{ic|graphical.target}} (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your bootloader:<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change {{ic|default.target}}. This can be done using {{ic|systemctl}}:<br />
{{bc|# systemctl enable multi-user.target}}<br />
<br />
The effect of this command is outputted by {{ic|systemctl}}; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
[Install]<br />
Alias=default.target<br />
is in the target's configuration file. Currently, {{ic|multi-user.target}} and {{ic|graphical.target}} both have it.<br />
<br />
== Running DEs under systemd ==<br />
<br />
=== Using display manager ===<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]] and [[LightDM]].<br />
<br />
{{bc|# systemctl enable kdm.service}}<br />
<br />
This should work out of the box. If not, you might have a {{ic|default.target}} set manually or from a older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and systemd will use its stock {{ic|default.target}} (i.e. {{ic|graphical.target}}).<br />
<br />
{{bc|# rm /etc/systemd/system/default.target}}<br />
<br />
=== Using service file ===<br />
{{Note|Using this method there will be no PAM session created for your user. Therefore ConsoleKit (which gives you access to shutdown/reboot, audio devices etc.) will not work properly. For the recommended way, see: [[#Replacing_ConsoleKit_with_systemd-logind|Replacing ConsoleKit with systemd-logind]] and [[Automatic_login_to_virtual_console#With_systemd]].}}<br />
If you are only looking for a simple way to start X directly without a display manager, you can create a service file similar to this:<br />
<br />
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|<nowiki><br />
[Unit]<br />
Description=Direct login to X<br />
After=systemd-user-sessions.service<br />
<br />
[Service]<br />
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"<br />
<br />
[Install]<br />
WantedBy=graphical.target<br />
</nowiki>}}<br />
<br />
== Systemd Journal ==<br />
Since version 38 systemd has an own logging system, the journal.<br />
<br />
By default, running a syslog daemon is no longer required. To read the log, use:<br />
{{bc|# journalctl}}<br />
The journal writes to {{ic|/run/systemd/journal}}, meaning logs will be lost on reboot. For non-volatile logs, create {{ic|/var/log/journal/}}:<br />
{{bc|# mkdir /var/log/journal/}}<br />
<br />
=== Filtering output ===<br />
<br />
{{ic|journalctl}} allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages by a specific executable:<br />
{{bc|# journalctl /usr/lib/systemd/systemd}}<br />
<br />
Show all messages by a specific process:<br />
{{bc|1=# journalctl _PID=1}}<br />
<br />
Show all messages by a specific unit:<br />
{{bc|1=# journalctl _SYSTEMD_UNIT=netcfg.service}}<br />
<br />
See {{ic|man journalctl}} and {{ic|systemd.journal-fields}} for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is made non-volatile, its size limit is set to a default value of 10% of the size of the respective file system. E.g. with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
{{bc|1=SystemMaxUse=50M}}<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
===Journald in conjunction with a classic syslog daemon===<br />
Compatibility with classic syslog implementations is provided via a<br />
socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded.<br />
To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). For syslog-ng, change the {{ic|source src}} section in {{ic|/etc/syslog-ng/syslog-ng.conf}} to:<br />
{{bc|<nowiki><br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};</nowiki>}}<br />
<br />
and enable syslog-ng:<br />
{{bc|# systemctl enable syslog-ng.service}}<br />
<br />
== Network ==<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
If you simply want to use DHCP for your Ethernet connection, you can use {{ic|dhcpcd@.service}} (provided by the {{Pkg|dhcpcd}} package).<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
=== Other configurations ===<br />
For static, wireless or advanced network configuration like bridging you can use [[Netcfg#systemd_support|netcfg]] or [[NetworkManager#Enable_NetworkManager_under_Native_systemd_system|NetworkManager]] which both provide systemd service files.<br />
{{Note|If you want to use netcfg, networkmanager or another software for managing the network you don't need to start/enable dhcpcd as seen on the previous paragraph.}}<br />
<br />
If you need a static Ethernet configuration, but don't want to use [[netcfg]], there is a custom service file available on the [[Systemd/Services#Static_Ethernet_network|Systemd/Services page]].<br />
<br />
== Arch integration ==<br />
=== Initscripts emulation ===<br />
Integration with Arch's classic configuration is provided by the {{Pkg|initscripts}} package. This is simply meant as a transitional measure to ease users' move to systemd.<br />
<br />
{{Note|{{ic|/etc/inittab}} is not used at all.}}<br />
<br />
If you disabled {{keypress|Ctrl+Alt+Del}} to reboot in {{ic|/etc/inittab}}, you will have to reconfigure this setting for systemd by running {{ic|systemctl mask ctrl-alt-del.target}} as root.<br />
<br />
==== rc.conf ====<br />
Some variables in {{ic|/etc/rc.conf}} are respected by this glue work. For a pure systemd setup, it is recommended to use the [[Systemd#Native_systemd_configuration_files|native systemd configuration files]] which will take precedence over {{ic|/etc/rc.conf}}.<br />
<br />
Supported variables:<br />
* {{ic|LOCALE}}<br />
* {{ic|KEYMAP}}<br />
* {{ic|CONSOLEFONT}}<br />
* {{ic|CONSOLEMAP}}<br />
* {{ic|HOSTNAME}}<br />
* {{ic|DAEMONS}}<br />
<br />
Not supported variables and systemd configuration:<br />
* {{ic|TIMEZONE}}: Please symlink {{Ic|/etc/localtime}} to your zoneinfo file manually.<br />
* {{ic|HARDWARECLOCK}}: See [[Systemd#Hardware clock time|Hardware clock time]].<br />
* {{ic|USELVM}}: use {{ic|lvm.service}} provided by {{Pkg|lvm2}} instead.<br />
* {{ic|USECOLOR}}<br />
* {{ic|MODULES}}<br />
<br />
=== Total conversion to native systemd ===<br />
{{Note|This is the preferred method, where the system does not rely on {{ic|rc.conf}} centralised configuration anymore, but uses native systemd configuration files.}}<br />
<br />
Follow system configuration as explained in [[#Native_systemd_configuration_files]]. Each file replaces one section of {{ic|/etc/rc.conf}} as shown in that table:<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Configuration<br />
! scope="col"| Configuration file(s)<br />
! scope="col"| Legacy {{ic|/etc/rc.conf}} section<br />
|-<br />
| align="center"|Hostname<br />
| align="left"|{{ic|/etc/hostname}}<br />
{{ic|/etc/hosts}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|-<br />
| align="center"|Console fonts and Keymap<br />
| align="left"|{{ic|/etc/vconsole.conf}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Locale<br />
| align="left"|{{ic|/etc/locale.conf}}<br />
{{ic|/etc/locale.gen}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Time zone<br />
| align="left"|{{ic|/etc/localtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Hardware clock<br />
| align="left"|{{ic|/etc/adjtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Kernel modules<br />
| align="left"|{{ic|/etc/modules-load.d/}}<br />
| align="center"|{{ic|HARDWARE}}<br />
|}<br />
<br />
For legacy purposes, the '''DAEMONS''' section in {{ic|/etc/rc.conf}} is still compatible with systemd and can be used to start services at boot, even with a "pure" systemd service management. Alternatively, you may remove the {{ic|/etc/rc.conf}} file entirely and enable services in systemd. For each {{ic|<service_name>}} in the '''DAEMONS''' array in {{ic|/etc/rc.conf}}, type:<br />
# systemctl enable <service_name>.service<br />
{{Tip|For a list of commonly used daemons with their initscripts and systemd equivalents, see [[Daemon#List_of_Daemons|this table]].}}<br />
<br />
If {{ic|<service_name>.service}} does not exist:<br />
* the service file may not be available for systemd. In that case, you'll need to keep {{ic|rc.conf}} to start the service during boot up.<br />
* systemd may name services differently, e.g. {{ic|cronie.service}} replaces {{ic|crond}} init daemon; {{ic|alsa-store.service}} and {{ic|alsa-restore.service}} replace the {{ic|alsa}} init daemon. Another important instance is the {{ic|network}} daemon, which is replaced with another set of service files (see [[#Network]] for more details.)<br />
{{Tip|You may look inside a package that contains daemon start scripts for service names. For instance:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #<-- daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #<-- corresponding systemd daemon service<br />
[...]<br />
}}<br />
* systemd will automatically handle the start order of these daemons.<br />
* some services do not need to be explicitly enabled by the user. For instance, {{ic|dbus.service}} will automatically be enabled when {{ic|dbus-core}} is installed. Check the list of available services and their state using the {{ic|systemctl}} command.<br />
<br />
==Writing custom .service files==<br />
===Handling dependencies===<br />
With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit {{ic|A}} requires the unit {{ic|B}} to be running before {{ic|A}} is started. In that case add {{ic|1=Requires=B}} and {{ic|1=After=B}} to the {{ic|[Unit]}} section of {{ic|A}}. If the dependency is optional, add {{ic|1=Wants=B}} and {{ic|1=After=B}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, {{ic|network.target}} is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since {{ic|network.target}} is started anyway.<br />
<br />
===Type===<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
* {{ic|1=Type=simple}}: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so systemd can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: This is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=}} as well so that systemd still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: Identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by {{ic|libsystemd-daemon.so}}.<br />
* {{ic|1=Type=dbus}}: The service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
===Replacing provided unit files===<br />
The unit files in {{ic|/etc/systemd/system/}} take precedence over the ones in {{ic|/usr/lib/systemd/system/}}.<br />
To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from {{ic|/usr/lib/}} to {{ic|/etc/}} and make your changes there. Alternatively you can use {{ic|.include}} to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:<br />
{{hc|/etc/systemd/system/<service-name>.service|<br />
<nowiki><br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency><br />
</nowiki>}}<br />
Then run the following for your changes to take effect:<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
{{Tip|You can use {{ic|systemd-delta}} to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
===Syntax highlighting for systemd unit files within Vim===<br />
Syntax highlighting for systemd unit files within [[Vim]] can be enabled by installing {{AUR|vim-systemd}} from the [[Arch User Repository|AUR]].<br />
<br />
== FAQ ==<br />
For an up-to-date list of known issues, look at the upstream [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].<br />
<br />
{{FAQ<br />
|question=Why are my console fonts ugly?<br />
|answer=If no font is set in {{ic|/etc/vconsole.conf}} (or alternatively {{ic|/etc/rc.conf}}), then a standard font will be used. The standard font is chosen due to it supporting a wide range of character sets. Set your preferred font to fix the issue.}}<br />
<br />
{{FAQ<br />
|question=Why do I get log messages on my console?<br />
|answer=You must set the kernel loglevel yourself. Historically, {{ic|/etc/rc.sysinit}} did this for us and set dmesg loglevel to {{ic|3}}, which was a reasonably quiet loglevel. Either add {{ic|1=loglevel=3}} or {{ic|quiet}} to your [[kernel parameters]].}}<br />
<br />
{{FAQ<br />
|question=How do I change the number of gettys running by default?<br />
|answer=To add another getty, simply place another symlink for instantiating another getty in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service<br />
# systemctl daemon-reload<br />
# systemctl start getty@tty9.service</nowiki>}}<br />
<br />
To remove a getty, simply remove the getty symlinks you want to get rid of in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service<br />
# systemctl daemon-reload<br />
# systemctl stop getty@tty5.service getty@tty6.service</nowiki>}}<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only 1 getty will be launched by default. If you switch to another tty, a getty will be launched there (socket-activation style). You can still force additional agetty processes to start using the above methods.}}}}<br />
<br />
{{FAQ<br />
|question=How do I get more verbose output during boot?<br />
|answer=If you see no output at all in console after the initram message, this means you have the {{ic|quiet}} parameter in your kernel line. It's best to remove it, at least the first time you boot with systemd, to see if everything is ok. Then, You will see a list {{ic|[ OK ]}} in green or {{ic|[ FAILED ]}} in red.<br />
<br />
Any messages are logged to the system log and if you want to find out about the status of your system run {{ic|systemctl}} (no root privileges required) or look at the boot/system log with {{ic|journalctl}}.<br />
}}<br />
<br />
{{FAQ<br />
|question=How do I avoid clearing the console after boot?<br />
|answer=Create a custom {{ic|getty@tty1.service}} file by copying {{ic|/usr/lib/systemd/system/getty@.service}} to {{ic|/etc/systemd/system/getty.target.wants/getty@tty1.service}} and change {{ic|TTYVTDisallocate}} to {{ic|no}}.<br />
}}<br />
<br />
{{FAQ<br />
|question=What kernel options do I need to enable in my kernel in case I do not use the official Arch kernel?<br />
|answer=Kernels prior to 2.6.39 are unsupported.<br />
<br />
This is a partial list of required/recommended options, there might be more:<br />
<br />
{{bc|<nowiki><br />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y|m] (highly recommended)<br />
CONFIG_UEVENT_HELPER_PATH=""<br />
CONFIG_DEVTMPFS=y<br />
CONFIG_DEVTMPFS_MOUNT=y (required if you don't use an initramfs)<br />
CONFIG_RTC_DRV_CMOS=y (highly recommended)<br />
CONFIG_FANOTIFY=y (required for readahead)<br />
CONFIG_AUTOFS4_FS=[y|m]<br />
CONFIG_TMPFS_POSIX_ACL=y (recommended, if you want to use pam_systemd.so)<br />
CONFIG_NAMESPACES=y (for Private*=yes)<br />
CONFIG_NET_NS=y (for PrivateNetwork=yes)<br />
CONFIG_FHANDLE=y<br />
</nowiki>}}}}<br />
<br />
{{FAQ<br />
|question=What other units does a unit depend on?<br />
|answer=For example, if you want to figure out which services a target like {{ic|multi-user.target}} pulls in, use something like this: <br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}<br />
<br />
Instead of {{ic|Wants}} you might also try {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} for the respective types of dependencies and their inverse.}}<br />
<br />
{{FAQ<br />
|question=My computer shuts down, but the power stays on.<br />
|answer=Use:<br />
$ systemctl poweroff<br />
Instead of {{ic|systemctl halt}}.}}<br />
<br />
{{FAQ<br />
|question=After migrating to systemd, why won't my fakeRAID mount?<br />
|answer=Be sure you use {{bc|# systemctl enable dmraid.service}}<br />
}}<br />
<br />
{{FAQ<br />
|question=How can I make a script start during the boot process?<br />
|answer=Create a new file in {{ic|/etc/systemd/system}} (e.g. ''myscript''.service) and add the following contents:<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
</nowiki>}}<br />
Then<br />
{{bc|# systemctl enable ''myscript''.service}}<br />
This example assumes you want your script to start up when the target multi-user is launched.<br />
}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal.<br />
In the case with iptables it is because there is no daemon to run, it is controlled in the kernel. Therefore it exits after the rules have been loaded.<br />
<br />
To check if your iptables rules have been loaded properly:<br />
{{bc|iptables --list}}<br />
}}<br />
<br />
== Optimization ==<br />
=== systemd-analyze ===<br />
Systemd provides a tool called {{ic|systemd-analyze}} that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install {{Pkg|python2-dbus}} and {{Pkg|python2-cairo}} to use it.<br />
<br />
To see how much time was spent in kernel-/userspace on boot, simply use:<br />
{{bc|$ systemd-analyze}}<br />
{{Tip|If you add the {{ic|timestamp}} hook to your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} and rebuild your initramfs, {{ic|systemd-analyze}} will also be able to show you how much time was spent in the initramfs.}}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
{{bc|$ systemd-analyze blame}}<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
{{bc|$ systemd-analyze plot > plot.svg}}<br />
<br />
====Enabling bootchart in conjunction with systemd====<br />
You can use a version of bootchart to visualize the boot sequence.<br />
Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2}} package from [[AUR]] comes with an undocumented systemd service. After you've installed bootchart2 do:<br />
{{bc|# systemctl enable bootchart.service}}<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
systemd daemon management requires a bit more text entry to accomplish tasks such as start, stopped, enabling, checking status, etc. The following functions can be added to one's {{ic|~/.bashrc}} file to help streamline interactions with systemd and to improve the overall experience.<br />
<br />
{{bc|<nowiki>if ! systemd-notify --booted; then # not using systemd<br />
start() {<br />
sudo rc.d start $1<br />
}<br />
<br />
restart() {<br />
sudo rc.d restart $1<br />
}<br />
<br />
stop() {<br />
sudo rc.d stop $1<br />
}<br />
else<br />
start() {<br />
sudo systemctl start $1<br />
}<br />
<br />
restart() {<br />
sudo systemctl restart $1<br />
}<br />
<br />
stop() {<br />
sudo systemctl stop $1<br />
}<br />
<br />
enable() {<br />
sudo systemctl enable $1<br />
}<br />
<br />
status() {<br />
sudo systemctl status $1<br />
}<br />
<br />
disable() {<br />
sudo systemctl disable $1<br />
}<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
=== Early start ===<br />
One central feature of systemd is [[D-Bus]] and socket activation, this causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like [[ConsoleKit]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
{{bc|# systemctl enable console-kit-daemon.service}}<br />
<br />
This will cause systemd to start ConsoleKit as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
=== Automount ===<br />
The default setup will fsck and mount all filesystems before starting most daemons and services. If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is being fsck'ed. This can be achieved by adding the following options to the fstab entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:<br />
{{hc|/etc/crypttab|data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:<br />
<br />
{{bc|<nowiki># systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service</nowiki>}}<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
=== Replacing ConsoleKit with systemd-logind ===<br />
Starting with {{Pkg|polkit}} 0.107 (currently in [testing]), [[ConsoleKit]] can be completely replaced by {{ic|systemd-logind}}. However, there is currently no Display Manager in the Arch Linux repositories which natively supports {{ic|systemd-logind}} without still depending on [[ConsoleKit]]. The easiest method to be able to remove [[ConsoleKit]] is to [[Automatic_login_to_virtual_console#With_systemd|automatically login to a virtual console]] and [[Start_X_at_Boot|start X from there]]. It is important that, as mentioned in the latter article, the X server is started on the same virtual console that you log in to, otherwise systemd can not keep track of the user session. You can then simply remove {{ic|ck-launch-session}} from your {{ic|~/.xinitrc}}.<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. To see if your user session is properly set up, check if the following command contains {{ic|1=Active=yes}}. All {{Pkg|polkit}} actions like suspending the system or mounting external drives with [[Udisks]] should then work automatically.<br />
$ loginctl show-session <session-id><br />
<br />
{{Note|If you use [[NetworkManager]], you have to recompile it with systemd support from the [[ABS]] by setting {{ic|1=--with-session-tracking=systemd}} in the [[PKGBUILD]].}}<br />
<br />
== Troubleshooting ==<br />
=== Shutdown/Reboot takes terribly long ===<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. systemd waits some time for each service to exit before trying to kill it.<br />
To find out if you are affected see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
==== SLiM and xfce-session ====<br />
One setup that can produce a shutdown freeze is Xfce in conjunction with SLiM: Shutting down/rebooting using xfce-session will cause slim.service to hang for half a minute until systemd kills it the hard way.<br />
One workaround is to create a modified {{ic|slim.service}}:<br />
{{hc|/etc/systemd/system/slim.service|<nowiki><br />
[Unit]<br />
Description=SLiM Simple Login Manager<br />
After=systemd-user-sessions.service<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/var/lock/slim.lock<br />
ExecStart=/usr/bin/slim -d<br />
ExecStop=/bin/kill -9 $MAINPID<br />
ExecStopPost=/bin/rm /var/lock/slim.lock<br />
<br />
[Install]<br />
WantedBy=graphical.target</nowiki>}}<br />
This causes SLiM to be terminated using SIGKILL. Since the lock file is also removed this does not cause a problem.<br />
<br />
=== If some services are failing to start ===<br />
<br />
If your {{ic|/var/tmp}} is a symbolic link to {{ic|/tmp}}, expect some services to fail when started via systemd. In these cases, the failure status of the processes (via {{ic|systemctl status <service>}}) will be "226/NAMESPACE". To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{pkg|filesystem}} package.<br />
<br />
=== Disable warning bell ===<br />
Add command {{ic|xset -b}} to the {{ic|.xinitrc}} file.<br />
Discussion on [https://bbs.archlinux.org/viewtopic.php?pid=1148781 this] forum topic.<br />
<br />
== See also==<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official Web Site]<br />
*[http://0pointer.de/public/systemd-man/ Manual Pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug Systemd problems]<br />
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Booting up: Tools and tips for systemd, a Linux init tool. In The H]<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]<br />
*[http://0pointer.de/blog/projects/why.html most recent summary]</div>Kopfwehhttps://wiki.archlinux.org/index.php?title=Systemd&diff=226530Systemd2012-10-02T14:41:36Z<p>Kopfweh: added lightdm</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[es:Systemd]]<br />
[[fr:Systemd]]<br />
[[it:Systemd]]<br />
[[ru:Systemd]]<br />
[[zh-CN:Systemd]]<br />
{{Article summary start}}<br />
{{Article summary text|Covers how to install and configure systemd.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Systemd/Services}}<br />
{{Article summary wiki|Init to systemd cheatsheet}}<br />
{{Article summary wiki|udev}} - systemd and udev have been merged upstream.<br />
{{Article summary end}}<br />
From the [http://freedesktop.org/wiki/Software/systemd project web page]:<br />
<br />
''"'''systemd''' is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and [[D-Bus]] activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux [[cgroups|control groups]], supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."''<br />
<br />
{{Note|For a detailed explanation as to why Arch is switching to systemd, see: [https://bbs.archlinux.org/viewtopic.php?pid&#61;1149530#p1149530 this forum post].}}<br />
<br />
See also the [[Wikipedia:Systemd|Wikipedia article]].<br />
<br />
== Things to consider before you switch ==<br />
<br />
* It is highly recommended to switch to the new '''initscripts''' configuration system described in the [[rc.conf|rc.conf article]]. Once you have this configuration established, you will have done most of the work needed to make the switch to systemd.<br />
* Do [http://freedesktop.org/wiki/Software/systemd/ some reading] about systemd.<br />
* Note the fact that systemd has a '''journal''' system that replaces '''syslog''', although the two can co-exist. See the [[#Journald_in_conjunction_with_a_classic_syslog_daemon|section on the journal]] below.<br />
* Do not worry about systemd's plans to replace the functionality of '''cron''', '''acpid''', or '''xinetd'''. These are not things you need to worry about just yet. For now, you can continue to use your traditional daemons for these tasks.<br />
<br />
== Installation ==<br />
systemd can be installed side-by-side with the regular Arch Linux {{pkg|initscripts}} package, and they can be toggled by adding/removing the {{Ic|1=init=/bin/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A pure systemd installation ===<br />
<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/bin/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Create [[#Native systemd configuration files|systemd configuration files]].<br />
# [[#Using_Units|Enable daemons]] formerly listed in {{ic|/etc/rc.conf}} with {{ic|systemctl enable ''daemonname.'''service''' ''}}. For a translation of the daemons from {{ic|/etc/rc.conf}} to systemd services, see: [[Daemon#List_of_Daemons|List of Daemons]] and [[Systemd/Services|Services]]<br />
# Reboot. Your system should now initialize with systemd. If you are satisfied, remove the {{ic|1=init=...}} entry.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
<br />
=== A mixed systemd installation ===<br />
<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]]<br />
# Add {{ic|1=init=/bin/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# We recommend that you use [[#Native systemd configuration files|native systemd configuration files]] instead of Arch's classic configuration files. You can still use {{ic|/etc/rc.conf}} to configure a few variables if the native configuration files do not exist, but support will be dropped in the future.<br />
# If you want to keep using syslog log files alongside the systemd journal, follow the instructions described in the [[#Journald_in_conjunction_with_a_classic_syslog_daemon|section on the journal]], below.<br />
<br />
=== Supplementary information ===<br />
{{Note|1=In a pure systemd installation, installing {{pkg|systemd-sysvcompat}} replaces {{pkg|sysvinit}} and creates symlinks to halt, reboot, etc.}}<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you should remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
{{Warning|{{ic|/usr}} must be mounted and available at bootup (this is not particular to systemd). If your {{ic|/usr}} is on a separate partition, you will need to make accommodations to mount it from the initramfs and unmount it from a pivoted root on shutdown. See [[Mkinitcpio#/usr_as_a_separate_partition|the mkinitcpio wiki page]] and [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken freedesktop.org#separate-usr-is-broken].}}<br />
<br />
== Native systemd configuration files ==<br />
{{Note|You may need to create these files.}}<br />
{{Pkg|systemd}} will use {{ic|/etc/rc.conf}} if these files are absent. Note this is temporary and not a long-term solution. It is strongly advised to use the systemd configuration files on any system.<br />
=== Hostname ===<br />
{{hc|/etc/hostname|myhostname}}<br />
<br />
=== Console and keymap ===<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
{{hc|/etc/vconsole.conf|<nowiki><br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni</nowiki>}}<br />
<br />
For more info see [[Fonts#Console_fonts|Console fonts]] and [[KEYMAP#Keyboard_layouts|Keymap]].<br />
<br />
{{Tip|To use the kernel compiled-in font and keymap rather than the systemd-default ones use<br />
{{hc|/etc/vconsole.conf|<nowiki><br />
KEYMAP=<br />
FONT=<br />
</nowiki>}}<br />
This might be the default in the future.<br />
}}<br />
<br />
=== Locale ===<br />
Read {{ic|man locale.conf}} for more options:<br />
{{hc|/etc/locale.conf|<nowiki><br />
LANG=en_US.UTF-8<br />
LC_COLLATE=C</nowiki>}}<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
Read {{ic|man 5 localtime}} for more options.<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
or, if you want to use a relative symlink:<br />
# ln -sf ../usr/share/zoneinfo/America/Chicago /etc/localtime<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
Systemd will use UTC for the hardware clock by default and this is recommended. Dealing with daylight saving time is messy. If the DST changes when your computer is off, your clock will be wrong on next boot ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]). Recent kernels set the system time from the RTC directly on boot without using {{ic|hwclock}}, the kernel will always assume that the RTC is in UTC. This means that if the RTC is in local time, then the system time will first be set up wrongly and then corrected shortly afterwards on every boot. This is possibly the reason for certain weird bugs (time going backwards is rarely a good thing).<br />
<br />
The reason for allowing the RTC to be in local time is to allow dual boot with Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). Windows is able to deal with the RTC being in UTC with a simple [[Time#UTC_in_Windows|registry fix]]. If you run into issues on dual boot with Windows, you can set the hardware clock to local time. Contrary to popular belief, systemd supports this:<br />
<br />
{{hc|/etc/adjtime|<br />
0.0 0.0 0.0<br />
0<br />
LOCAL}}<br />
<br />
The other parameters are still needed but are ignored by systemd.<br />
<br />
It is generally advised to have a [[NTP|Network Time Protocol daemon]] running to keep the hardware clock synchronized with the system time.<br />
<br />
=== Kernel modules loaded during boot ===<br />
systemd uses {{ic|/etc/modules-load.d/}} to configure kernel modules to load during boot in a static list. Each configuration file is named in the style of {{ic|/etc/modules-load.d/<program>.conf}}. The configuration files should simply contain a list of kernel module names to load, separated by newlines. Empty lines and lines whose first non-whitespace character is {{ic|#}} or {{ic|;}} are ignored. Example:<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<nowiki><br />
# Load virtio-net.ko at boot<br />
virtio-net</nowiki>}}<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
Module blacklisting works the same way as with {{Pkg|initscripts}} since it is actually handled by {{Pkg|kmod}}. See [[Kernel_modules#Blacklisting|Module Blacklisting]] for details.<br />
<br />
=== Temporary files ===<br />
Systemd-tmpfiles uses the configuration files in {{ic|/usr/lib/tmpfiles.d/}} and {{ic|/etc/tmpfiles.d/}} to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as {{ic|/run}} or {{ic|/tmp}}. Each configuration file is named in the style of {{ic|/etc/tmpfiles.d/<program>.conf}}. This will also override any files in {{ic|/usr/lib/tmpfiles.d/}} with the same name.<br />
<br />
tmpfiles are usually provided together with service files to create directories which are expected to exist by certain daemons. For example the [[Samba]] daemon expects the directory {{ic|/var/run/samba}} to exist and to have the correct permissions. The corresponding tmpfile looks like this:<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root<br />
}}<br />
<br />
However, tmpfiles may also be used to write values into certain files on boot. For example, if you use {{ic|/etc/rc.local}} to disable wakeup from USB devices with {{ic|echo USBE > /proc/acpi/wakeup}}, you may use the following tmpfile instead:<br />
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|<br />
w /proc/acpi/wakeup - - - - USBE<br />
}}<br />
The tmpfiles method is recommended in this case since systemd doesn't actually support {{ic|/etc/rc.local}}.<br />
<br />
See {{ic|man tmpfiles.d}} for details.<br />
<br />
=== Remote filesystem mounts ===<br />
systemd automatically makes sure that remote filesystem mounts like [[NFS]] or [[Samba]] are only started after the network has been set up. Therefore remote filesystem mounts specified in {{ic|/etc/fstab}} should work out of the box.<br />
<br />
You may however want to use [[#Automount|Automount]] for remote filesystem mounts to mount them only upon access. Furthermore you can use the {{ic|1=x-systemd.device-timeout=#}} option in {{ic|/etc/fstab}} to specify a timeout in case the network resource is not available.<br />
<br />
See {{ic|man systemd.mount}} for details.<br />
<br />
=== ACPI Power Management with systemd ===<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
* {{ic|HandlePowerKey}}: specifies which action is invoked when the power key is pressed<br />
* {{ic|HandleSuspendKey}}: specifies which action is invoked when the suspend key is pressed<br />
* {{ic|HandleHibernateKey}}: specifies which action is invoked when the hibernate key is pressed<br />
* {{ic|HandleLidSwitch}}: specifies which action is invoked when the lid is closed<br />
The specified action can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} or {{ic|kexec}}.<br />
<br />
If these options are not configured, systemd will use it's defaults: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, and {{ic|1=HandleLidSwitch=suspend}}.<br />
<br />
On systems which run no graphical setup or only a simple window manager like [[i3]] or [[awesome]], this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
{{Note|If you want to continue using the acpid daemon to handle these events, you will need to set these options to {{ic|ignore}} or they will try to be handled twice.}}<br />
==== "Inhibited" ACPI events ====<br />
In the current version of systemd, the {{ic|Handle}} options will apply throughout the system unless they are "inhibited" (temporarily turned off) by a program, such as a power manager inside a desktop environment. If you want systemd to always handle these events, you can tell it to ignore the inhibited signals with the following options in {{ic|/etc/systemd/logind.conf}}:<br />
*{{ic|PowerKeyIgnoreInhibited}}<br />
*{{ic|SuspendKeyIgnoreInhibited}}<br />
*{{ic|HibernateKeyIgnoreInhibited}}<br />
*{{ic|LidSwitchIgnoreInhibited}}<br />
All of these default to no, except {{ic|LidSwitchIgnoreInhibited}}.<br />
{{Warning|If you want your desktop environment's power manager to handle the LidSwitch event you MUST set {{ic|1=LidSwitchIgnoreInhibited=no}}}}<br />
{{Note|Currently, no power managers issue the necessary "inhibited" commands. Until they do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[KDE]], [[GNOME]], [[Xfce]], or others. New versions are on the way that will include this functionality.}}<br />
<br />
=== Sleep hooks ===<br />
<br />
Systemd does not use [[pm-utils]] to put the machine to sleep when using {{ic|systemctl suspend}} or {{ic|systemctl hibernate}}, therefore [[pm-utils]] hooks including any [[Pm-utils#Creating_your_own_hooks|custom hooks]] created will not be run. However, systemd provides a similar mechanism to run custom scripts on these events. Systemd runs all executables in {{ic|/usr/lib/systemd/system-sleep/}} and passes two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: either {{ic|suspend}} or {{ic|hibernate}}, depending on what has been invoked<br />
<br />
In contrast to [[pm-utils]], systemd will run these scripts in parallel and not one after another.<br />
<br />
The output of your script will be logged by {{ic|systemd-suspend.service}} or {{ic|systemd-hibernate.service}} so you can see its output in the [[Systemd#Systemd Journal|journal]].<br />
<br />
Note that you can also use {{ic|sleep.target}}, {{ic|suspend.target}} or {{ic|hibernate.target}} to hook units into the sleep state logic instead of using scripts.<br />
<br />
See {{ic|man systemd.special}} and {{ic|man systemd-sleep}} for more information.<br />
<br />
==== Example ====<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki><br />
#!/bin/sh<br />
<br />
case "$1" in<br />
pre )<br />
echo going to $2 ...<br />
;;<br />
post )<br />
echo waking up from $2 ...<br />
;;<br />
esac</nowiki>}}<br />
<br />
=== Unit ===<br />
A unit configuration file encodes information about a service, a socket, a device, a mount point, an automount point, a swap file or partition, a start-up target, a file system path or a timer controlled and supervised by systemd. The syntax is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files. See {{ic|man systemd.unit}} for more info.<br />
<br />
== Systemd commands ==<br />
<br />
*{{ic|systemctl}}: used to introspect and control the state of the systemd system and service manager.<br />
*{{ic|systemd-cgls}}: recursively shows the contents of the selected Linux control group hierarchy in a tree<br />
*{{ic|systemadm}}: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd (available via the {{AUR|systemd-ui-git}} package from the [[AUR]]).<br />
<br />
View the man pages for more details. <br />
<br />
{{Tip|You can use all of the following {{ic|systemctl}} commands with the {{ic|-H <user>@<host>}} switch to control a systemd instance on a remote machine. This will use [[SSH]] to connect to the remote systemd instance.}}<br />
<br />
=== Analyzing the system state ===<br />
<br />
List running units:<br />
<br />
{{bc|$ systemctl}}<br />
<br />
or:<br />
<br />
{{bc|$ systemctl list-units}}<br />
<br />
List failed units:<br />
<br />
{{bc|$ systemctl --failed}}<br />
<br />
The available unit files can be seen in {{ic|/usr/lib/systemd/system/}} and {{ic|/etc/systemd/system/}} (the latter takes precedence). You can see list installed unit files by:<br />
{{bc|$ systemctl list-unit-files}}<br />
<br />
=== Using Units ===<br />
<br />
Units can be, for example, services ({{ic|.service}}), mount points ({{ic|.mount}}), devices ({{ic|.device}}) or sockets ({{ic|.socket}}).<br />
When using {{ic|systemctl}}, you generally have to specify the complete name of the unit file, including its suffix, for example {{ic|sshd.socket}}. There are however a few shortforms when specifying the unit in the following {{ic|systemctl}} commands:<br />
* If you don't specify the suffix, systemctl will assume {{ic|.service}}. For example, {{ic|netcfg}} and {{ic|netcfg.service}} are treated equivalent. {{Note|This currently does not work with the commands {{ic|enable}} and {{ic|disable}}.}}<br />
* Mount points will automatically be translated into the appropriate {{ic|.mount}} unit. For example, specifying {{ic|/home}} is equivalent to {{ic|home.mount}}.<br />
* Similiar to mount points, devices are automatically translated into the appropriate {{ic|.device}} unit, therefore specifying {{ic|/dev/sda2}} is equivalent to {{ic|dev-sda2.device}}.<br />
<br />
See {{ic|man systemd.unit}} for details.<br />
<br />
Activate a unit immediately:<br />
<br />
{{bc|# systemctl start <unit>}}<br />
<br />
Deactivate a unit immediately:<br />
<br />
{{bc|# systemctl stop <unit>}}<br />
<br />
Restart a unit:<br />
<br />
{{bc|# systemctl restart <unit>}}<br />
<br />
Ask a unit to reload its configuration:<br />
<br />
{{bc|# systemctl reload <unit>}}<br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
{{bc|$ systemctl status <unit>}}<br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
{{bc|$ systemctl is-enabled <unit>}}<br />
<br />
Enable a unit to be started on bootup:<br />
<br />
{{bc|# systemctl enable <unit>}}<br />
<br />
{{Note| If services do not have an Install section, it usually means they are called automatically by other services. But if you need to install them manually, use the following command, replacing ''foo'' with the name of the service.<br />
<br />
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}<br />
<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
{{bc|# systemctl disable <unit>}}<br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
{{bc|$ systemctl help <unit>}}<br />
<br />
=== Power Management ===<br />
<br />
If you are in a local {{ic|systemd-logind}} or [[ConsoleKit]] user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password (see also [[#Replacing_ConsoleKit_with_systemd-logind|Replacing ConsoleKit with systemd-logind]]).<br />
<br />
Shut down and reboot the system:<br />
<br />
{{bc|$ systemctl reboot}}<br />
<br />
Shut down and power-off the system:<br />
<br />
{{bc|$ systemctl poweroff}}<br />
<br />
Shut down and halt the system:<br />
<br />
{{bc|$ systemctl halt}}<br />
<br />
Suspend the system:<br />
<br />
{{bc|$ systemctl suspend}}<br />
<br />
Hibernate the system:<br />
<br />
{{bc|$ systemctl hibernate}}<br />
<br />
== Runlevels/targets ==<br />
Runlevels is a legacy concept in systemd. Systemd uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''targets'' are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are systemd ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command. <br />
<br />
=== Get current runlevel/targets ===<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
{{bc|1=# systemctl list-units --type=target}}<br />
<br />
=== Create custom target ===<br />
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named systemd ''target'' as {{ic|/etc/systemd/system/<your target>}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/<your target>.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.<br />
<br />
=== Targets table ===<br />
{| border="1"<br />
!SysV Runlevel!!Systemd Target!!Notes<br />
|-<br />
| 0 || runlevel0.target, poweroff.target || Halt the system.<br />
|-<br />
| 1, s, single || runlevel1.target, rescue.target || Single user mode.<br />
|-<br />
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || User-defined/Site-specific runlevels. By default, identical to 3.<br />
|-<br />
| 3 || runlevel3.target, multi-user.target || Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.<br />
|-<br />
| 5 || runlevel5.target, graphical.target || Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.<br />
|-<br />
| 6 || runlevel6.target, reboot.target || Reboot<br />
|-<br />
| emergency || emergency.target || Emergency shell<br />
|-<br />
|}<br />
<br />
=== Change current runlevels ===<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
{{bc|# systemctl isolate graphical.target}}<br />
This will only change the current runlevel, and has no effect on the next boot. This is equivalent to commands such as {{ic|telinit 3}} or {{ic|telinit 5}} in Sysvinit.<br />
<br />
=== Change default runlevel/target to boot into ===<br />
The standard target is {{ic|default.target}}, which is aliased by default to {{ic|graphical.target}} (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your bootloader:<br />
* {{ic|1=systemd.unit=multi-user.target}} (which roughly corresponds to the old runlevel 3),<br />
* {{ic|1=systemd.unit=rescue.target}} (which roughly corresponds to the old runlevel 1).<br />
<br />
Alternatively, you may leave the bootloader alone and change {{ic|default.target}}. This can be done using {{ic|systemctl}}:<br />
{{bc|# systemctl enable multi-user.target}}<br />
<br />
The effect of this command is outputted by {{ic|systemctl}}; a symlink to the new default target is made at {{ic|/etc/systemd/system/default.target}}. This works if, and only if:<br />
[Install]<br />
Alias=default.target<br />
is in the target's configuration file. Currently, {{ic|multi-user.target}} and {{ic|graphical.target}} both have it.<br />
<br />
== Running DEs under systemd ==<br />
<br />
=== Using display manager ===<br />
To enable graphical login, run your preferred [[Display Manager]] daemon (e.g. [[KDM]]). At the moment, service files exist for [[GDM]], [[KDM]], [[SLiM]], [[XDM]],[[LXDM]] and [[LightDM]].<br />
<br />
{{bc|# systemctl enable kdm.service}}<br />
<br />
This should work out of the box. If not, you might have a {{ic|default.target}} set manually or from a older install:<br />
<br />
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}<br />
<br />
Simply delete the symlink and systemd will use its stock {{ic|default.target}} (i.e. {{ic|graphical.target}}).<br />
<br />
{{bc|# rm /etc/systemd/system/default.target}}<br />
<br />
=== Using service file ===<br />
{{Note|Using this method there will be no PAM session created for your user. Therefore ConsoleKit (which gives you access to shutdown/reboot, audio devices etc.) will not work properly. For the recommended way, see: [[#Replacing_ConsoleKit_with_systemd-logind|Replacing ConsoleKit with systemd-logind]] and [[Automatic_login_to_virtual_console#With_systemd]].}}<br />
If you are only looking for a simple way to start X directly without a display manager, you can create a service file similar to this:<br />
<br />
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|<nowiki><br />
[Unit]<br />
Description=Direct login to X<br />
After=systemd-user-sessions.service<br />
<br />
[Service]<br />
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"<br />
<br />
[Install]<br />
WantedBy=graphical.target<br />
</nowiki>}}<br />
<br />
== Systemd Journal ==<br />
Since version 38 systemd has an own logging system, the journal.<br />
<br />
By default, running a syslog daemon is no longer required. To read the log, use:<br />
{{bc|# journalctl}}<br />
The journal writes to {{ic|/run/systemd/journal}}, meaning logs will be lost on reboot. For non-volatile logs, create {{ic|/var/log/journal/}}:<br />
{{bc|# mkdir /var/log/journal/}}<br />
<br />
=== Filtering output ===<br />
<br />
{{ic|journalctl}} allows you to filter the output by specific fields.<br />
<br />
Examples:<br />
<br />
Show all messages by a specific executable:<br />
{{bc|# journalctl /usr/lib/systemd/systemd}}<br />
<br />
Show all messages by a specific process:<br />
{{bc|1=# journalctl _PID=1}}<br />
<br />
Show all messages by a specific unit:<br />
{{bc|1=# journalctl _SYSTEMD_UNIT=netcfg.service}}<br />
<br />
See {{ic|man journalctl}} and {{ic|systemd.journal-fields}} for details.<br />
<br />
=== Journal size limit ===<br />
<br />
If the journal is made non-volatile, its size limit is set to a default value of 10% of the size of the respective file system. E.g. with {{ic|/var/log/journal}} located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by {{ic|SystemMaxUse}} in {{ic|/etc/systemd/journald.conf}}, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:<br />
{{bc|1=SystemMaxUse=50M}}<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
===Journald in conjunction with a classic syslog daemon===<br />
Compatibility with classic syslog implementations is provided via a<br />
socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded.<br />
To make the syslog daemon work with the journal, it has to bind to this socket instead of {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). For syslog-ng, change the {{ic|source src}} section in {{ic|/etc/syslog-ng/syslog-ng.conf}} to:<br />
{{bc|<nowiki><br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};</nowiki>}}<br />
<br />
and enable syslog-ng:<br />
{{bc|# systemctl enable syslog-ng.service}}<br />
<br />
== Network ==<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
If you simply want to use DHCP for your Ethernet connection, you can use {{ic|dhcpcd@.service}} (provided by the {{Pkg|dhcpcd}} package).<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
=== Other configurations ===<br />
For static, wireless or advanced network configuration like bridging you can use [[Netcfg#systemd_support|netcfg]] or [[NetworkManager#Enable_NetworkManager_under_Native_systemd_system|NetworkManager]] which both provide systemd service files.<br />
{{Note|If you want to use netcfg, networkmanager or another software for managing the network you don't need to start/enable dhcpcd as seen on the previous paragraph.}}<br />
<br />
If you need a static Ethernet configuration, but don't want to use [[netcfg]], there is a custom service file available on the [[Systemd/Services#Static_Ethernet_network|Systemd/Services page]].<br />
<br />
== Arch integration ==<br />
=== Initscripts emulation ===<br />
Integration with Arch's classic configuration is provided by the {{Pkg|initscripts}} package. This is simply meant as a transitional measure to ease users' move to systemd.<br />
<br />
{{Note|{{ic|/etc/inittab}} is not used at all.}}<br />
<br />
If you disabled {{keypress|Ctrl+Alt+Del}} to reboot in {{ic|/etc/inittab}}, you will have to reconfigure this setting for systemd by running {{ic|systemctl mask ctrl-alt-del.target}} as root.<br />
<br />
==== rc.conf ====<br />
Some variables in {{ic|/etc/rc.conf}} are respected by this glue work. For a pure systemd setup, it is recommended to use the [[Systemd#Native_systemd_configuration_files|native systemd configuration files]] which will take precedence over {{ic|/etc/rc.conf}}.<br />
<br />
Supported variables:<br />
* {{ic|LOCALE}}<br />
* {{ic|KEYMAP}}<br />
* {{ic|CONSOLEFONT}}<br />
* {{ic|CONSOLEMAP}}<br />
* {{ic|HOSTNAME}}<br />
* {{ic|DAEMONS}}<br />
<br />
Not supported variables and systemd configuration:<br />
* {{ic|TIMEZONE}}: Please symlink {{Ic|/etc/localtime}} to your zoneinfo file manually.<br />
* {{ic|HARDWARECLOCK}}: See [[Systemd#Hardware clock time|Hardware clock time]].<br />
* {{ic|USELVM}}: use {{ic|lvm.service}} provided by {{Pkg|lvm2}} instead.<br />
* {{ic|USECOLOR}}<br />
* {{ic|MODULES}}<br />
<br />
=== Total conversion to native systemd ===<br />
{{Note|This is the preferred method, where the system does not rely on {{ic|rc.conf}} centralised configuration anymore, but uses native systemd configuration files.}}<br />
<br />
Follow system configuration as explained in [[#Native_systemd_configuration_files]]. Each file replaces one section of {{ic|/etc/rc.conf}} as shown in that table:<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Configuration<br />
! scope="col"| Configuration file(s)<br />
! scope="col"| Legacy {{ic|/etc/rc.conf}} section<br />
|-<br />
| align="center"|Hostname<br />
| align="left"|{{ic|/etc/hostname}}<br />
{{ic|/etc/hosts}}<br />
| align="center"|{{ic|NETWORKING}}<br />
|-<br />
| align="center"|Console fonts and Keymap<br />
| align="left"|{{ic|/etc/vconsole.conf}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Locale<br />
| align="left"|{{ic|/etc/locale.conf}}<br />
{{ic|/etc/locale.gen}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Time zone<br />
| align="left"|{{ic|/etc/localtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Hardware clock<br />
| align="left"|{{ic|/etc/adjtime}}<br />
| align="center"|{{ic|LOCALIZATION}}<br />
|-<br />
| align="center"|Kernel modules<br />
| align="left"|{{ic|/etc/modules-load.d/}}<br />
| align="center"|{{ic|HARDWARE}}<br />
|}<br />
<br />
For legacy purposes, the '''DAEMONS''' section in {{ic|/etc/rc.conf}} is still compatible with systemd and can be used to start services at boot, even with a "pure" systemd service management. Alternatively, you may remove the {{ic|/etc/rc.conf}} file entirely and enable services in systemd. For each {{ic|<service_name>}} in the '''DAEMONS''' array in {{ic|/etc/rc.conf}}, type:<br />
# systemctl enable <service_name>.service<br />
{{Tip|For a list of commonly used daemons with their initscripts and systemd equivalents, see [[Daemon#List_of_Daemons|this table]].}}<br />
<br />
If {{ic|<service_name>.service}} does not exist:<br />
* the service file may not be available for systemd. In that case, you'll need to keep {{ic|rc.conf}} to start the service during boot up.<br />
* systemd may name services differently, e.g. {{ic|cronie.service}} replaces {{ic|crond}} init daemon; {{ic|alsa-store.service}} and {{ic|alsa-restore.service}} replace the {{ic|alsa}} init daemon. Another important instance is the {{ic|network}} daemon, which is replaced with another set of service files (see [[#Network]] for more details.)<br />
{{Tip|You may look inside a package that contains daemon start scripts for service names. For instance:<br />
$ pacman -Ql cronie<br />
[...]<br />
cronie /etc/rc.d/crond #<-- daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)<br />
[...]<br />
cronie /usr/lib/systemd/system/cronie.service #<-- corresponding systemd daemon service<br />
[...]<br />
}}<br />
* systemd will automatically handle the start order of these daemons.<br />
* some services do not need to be explicitly enabled by the user. For instance, {{ic|dbus.service}} will automatically be enabled when {{ic|dbus-core}} is installed. Check the list of available services and their state using the {{ic|systemctl}} command.<br />
<br />
==Writing custom .service files==<br />
===Handling dependencies===<br />
With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit {{ic|A}} requires the unit {{ic|B}} to be running before {{ic|A}} is started. In that case add {{ic|1=Requires=B}} and {{ic|1=After=B}} to the {{ic|[Unit]}} section of {{ic|A}}. If the dependency is optional, add {{ic|1=Wants=B}} and {{ic|1=After=B}} instead. Note that {{ic|1=Wants=}} and {{ic|1=Requires=}} do not imply {{ic|1=After=}}, meaning that if {{ic|1=After=}} is not specified, the two units will be started in parallel.<br />
<br />
Dependencies are typically placed on services and not on targets. For example, {{ic|network.target}} is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since {{ic|network.target}} is started anyway.<br />
<br />
===Type===<br />
There are several different start-up types to consider when writing a custom service file. This is set with the {{ic|1=Type=}} parameter in the {{ic|[Service]}} section. See {{ic|man systemd.service}} for a more detailed explanation.<br />
* {{ic|1=Type=simple}}: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.<br />
* {{ic|1=Type=forking}}: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify {{ic|1=PIDFile=}} as well so systemd can keep track of the main process.<br />
* {{ic|1=Type=oneshot}}: This is useful for scripts that do a single job and then exit. You may want to set {{ic|1=RemainAfterExit=}} as well so that systemd still considers the service as active after the process has exited.<br />
* {{ic|1=Type=notify}}: Identical to {{ic|1=Type=simple}}, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by {{ic|libsystemd-daemon.so}}.<br />
* {{ic|1=Type=dbus}}: The service is considered ready when the specified {{ic|BusName}} appears on DBus's system bus.<br />
<br />
===Replacing provided unit files===<br />
The unit files in {{ic|/etc/systemd/system/}} take precedence over the ones in {{ic|/usr/lib/systemd/system/}}.<br />
To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from {{ic|/usr/lib/}} to {{ic|/etc/}} and make your changes there. Alternatively you can use {{ic|.include}} to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:<br />
{{hc|/etc/systemd/system/<service-name>.service|<br />
<nowiki><br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency><br />
</nowiki>}}<br />
Then run the following for your changes to take effect:<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
{{Tip|You can use {{ic|systemd-delta}} to see which unit files have been overridden and what exactly has been changed.}}<br />
<br />
===Syntax highlighting for systemd unit files within Vim===<br />
Syntax highlighting for systemd unit files within [[Vim]] can be enabled by installing {{AUR|vim-systemd}} from the [[Arch User Repository|AUR]].<br />
<br />
== FAQ ==<br />
For an up-to-date list of known issues, look at the upstream [http://cgit.freedesktop.org/systemd/systemd/tree/TODO TODO].<br />
<br />
{{FAQ<br />
|question=Why are my console fonts ugly?<br />
|answer=If no font is set in {{ic|/etc/vconsole.conf}} (or alternatively {{ic|/etc/rc.conf}}), then a standard font will be used. The standard font is chosen due to it supporting a wide range of character sets. Set your preferred font to fix the issue.}}<br />
<br />
{{FAQ<br />
|question=Why do I get log messages on my console?<br />
|answer=You must set the kernel loglevel yourself. Historically, {{ic|/etc/rc.sysinit}} did this for us and set dmesg loglevel to {{ic|3}}, which was a reasonably quiet loglevel. Either add {{ic|1=loglevel=3}} or {{ic|quiet}} to your [[kernel parameters]].}}<br />
<br />
{{FAQ<br />
|question=How do I change the number of gettys running by default?<br />
|answer=To add another getty, simply place another symlink for instantiating another getty in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service<br />
# systemctl daemon-reload<br />
# systemctl start getty@tty9.service</nowiki>}}<br />
<br />
To remove a getty, simply remove the getty symlinks you want to get rid of in the {{ic|/etc/systemd/system/getty.target.wants/}} directory:<br />
<br />
{{bc|<nowiki># rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service<br />
# systemctl daemon-reload<br />
# systemctl stop getty@tty5.service getty@tty6.service</nowiki>}}<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only 1 getty will be launched by default. If you switch to another tty, a getty will be launched there (socket-activation style). You can still force additional agetty processes to start using the above methods.}}}}<br />
<br />
{{FAQ<br />
|question=How do I get more verbose output during boot?<br />
|answer=If you see no output at all in console after the initram message, this means you have the {{ic|quiet}} parameter in your kernel line. It's best to remove it, at least the first time you boot with systemd, to see if everything is ok. Then, You will see a list {{ic|[ OK ]}} in green or {{ic|[ FAILED ]}} in red.<br />
<br />
Any messages are logged to the system log and if you want to find out about the status of your system run {{ic|systemctl}} (no root privileges required) or look at the boot/system log with {{ic|journalctl}}.<br />
}}<br />
<br />
{{FAQ<br />
|question=How do I avoid clearing the console after boot?<br />
|answer=Create a custom {{ic|getty@tty1.service}} file by copying {{ic|/usr/lib/systemd/system/getty@.service}} to {{ic|/etc/systemd/system/getty.target.wants/getty@tty1.service}} and change {{ic|TTYVTDisallocate}} to {{ic|no}}.<br />
}}<br />
<br />
{{FAQ<br />
|question=What kernel options do I need to enable in my kernel in case I do not use the official Arch kernel?<br />
|answer=Kernels prior to 2.6.39 are unsupported.<br />
<br />
This is a partial list of required/recommended options, there might be more:<br />
<br />
{{bc|<nowiki><br />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y|m] (highly recommended)<br />
CONFIG_UEVENT_HELPER_PATH=""<br />
CONFIG_DEVTMPFS=y<br />
CONFIG_DEVTMPFS_MOUNT=y (required if you don't use an initramfs)<br />
CONFIG_RTC_DRV_CMOS=y (highly recommended)<br />
CONFIG_FANOTIFY=y (required for readahead)<br />
CONFIG_AUTOFS4_FS=[y|m]<br />
CONFIG_TMPFS_POSIX_ACL=y (recommended, if you want to use pam_systemd.so)<br />
CONFIG_NAMESPACES=y (for Private*=yes)<br />
CONFIG_NET_NS=y (for PrivateNetwork=yes)<br />
CONFIG_FHANDLE=y<br />
</nowiki>}}}}<br />
<br />
{{FAQ<br />
|question=What other units does a unit depend on?<br />
|answer=For example, if you want to figure out which services a target like {{ic|multi-user.target}} pulls in, use something like this: <br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}<br />
<br />
Instead of {{ic|Wants}} you might also try {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} for the respective types of dependencies and their inverse.}}<br />
<br />
{{FAQ<br />
|question=My computer shuts down, but the power stays on.<br />
|answer=Use:<br />
$ systemctl poweroff<br />
Instead of {{ic|systemctl halt}}.}}<br />
<br />
{{FAQ<br />
|question=After migrating to systemd, why won't my fakeRAID mount?<br />
|answer=Be sure you use {{bc|# systemctl enable dmraid.service}}<br />
}}<br />
<br />
{{FAQ<br />
|question=How can I make a script start during the boot process?<br />
|answer=Create a new file in {{ic|/etc/systemd/system}} (e.g. ''myscript''.service) and add the following contents:<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
</nowiki>}}<br />
Then<br />
{{bc|# systemctl enable ''myscript''.service}}<br />
This example assumes you want your script to start up when the target multi-user is launched.<br />
}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal.<br />
In the case with iptables it is because there is no daemon to run, it is controlled in the kernel. Therefore it exits after the rules have been loaded.<br />
<br />
To check if your iptables rules have been loaded properly:<br />
{{bc|iptables --list}}<br />
}}<br />
<br />
== Optimization ==<br />
=== systemd-analyze ===<br />
Systemd provides a tool called {{ic|systemd-analyze}} that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install {{Pkg|python2-dbus}} and {{Pkg|python2-cairo}} to use it.<br />
<br />
To see how much time was spent in kernel-/userspace on boot, simply use:<br />
{{bc|$ systemd-analyze}}<br />
{{Tip|If you add the {{ic|timestamp}} hook to your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} and rebuild your initramfs, {{ic|systemd-analyze}} will also be able to show you how much time was spent in the initramfs.}}<br />
<br />
To list the started unit files, sorted by the time each of them took to start up:<br />
{{bc|$ systemd-analyze blame}}<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
{{bc|$ systemd-analyze plot > plot.svg}}<br />
<br />
====Enabling bootchart in conjunction with systemd====<br />
You can use a version of bootchart to visualize the boot sequence.<br />
Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the {{AUR|bootchart2}} package from [[AUR]] comes with an undocumented systemd service. After you've installed bootchart2 do:<br />
{{bc|# systemctl enable bootchart.service}}<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
systemd daemon management requires a bit more text entry to accomplish tasks such as start, stopped, enabling, checking status, etc. The following functions can be added to one's {{ic|~/.bashrc}} file to help streamline interactions with systemd and to improve the overall experience.<br />
<br />
{{bc|<nowiki>if ! systemd-notify --booted; then # not using systemd<br />
start() {<br />
sudo rc.d start $1<br />
}<br />
<br />
restart() {<br />
sudo rc.d restart $1<br />
}<br />
<br />
stop() {<br />
sudo rc.d stop $1<br />
}<br />
else<br />
start() {<br />
sudo systemctl start $1<br />
}<br />
<br />
restart() {<br />
sudo systemctl restart $1<br />
}<br />
<br />
stop() {<br />
sudo systemctl stop $1<br />
}<br />
<br />
enable() {<br />
sudo systemctl enable $1<br />
}<br />
<br />
status() {<br />
sudo systemctl status $1<br />
}<br />
<br />
disable() {<br />
sudo systemctl disable $1<br />
}<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
Change {{ic|verbose}} to {{ic|quiet}} on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.<br />
<br />
=== Early start ===<br />
One central feature of systemd is [[D-Bus]] and socket activation, this causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like [[ConsoleKit]]) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:<br />
<br />
{{bc|# systemctl enable console-kit-daemon.service}}<br />
<br />
This will cause systemd to start ConsoleKit as soon as possible, without causing races with the socket or D-Bus activation.<br />
<br />
=== Automount ===<br />
The default setup will fsck and mount all filesystems before starting most daemons and services. If you have a large {{ic|/home}} partition, it might be better to allow services that do not depend on {{ic|/home}} to start while {{ic|/home}} is being fsck'ed. This can be achieved by adding the following options to the fstab entry of your {{ic|/home}} partition:<br />
<br />
noauto,x-systemd.automount<br />
<br />
This will fsck and mount {{ic|/home}} when it is first accessed, and the kernel will buffer all file access to {{ic|/home}} until it is ready.<br />
<br />
If you have encrypted filesystems with keyfiles, you can also add the {{ic|noauto}} parameter to the corresponding entries in {{ic|/etc/crypttab}}. systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:<br />
{{hc|/etc/crypttab|data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:<br />
<br />
{{bc|<nowiki># systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service</nowiki>}}<br />
<br />
Remember that in order for the readahead to work its magic, you should reboot a couple of times.<br />
<br />
=== Replacing ConsoleKit with systemd-logind ===<br />
Starting with {{Pkg|polkit}} 0.107 (currently in [testing]), [[ConsoleKit]] can be completely replaced by {{ic|systemd-logind}}. However, there is currently no Display Manager in the Arch Linux repositories which natively supports {{ic|systemd-logind}} without still depending on [[ConsoleKit]]. The easiest method to be able to remove [[ConsoleKit]] is to [[Automatic_login_to_virtual_console#With_systemd|automatically login to a virtual console]] and [[Start_X_at_Boot|start X from there]]. It is important that, as mentioned in the latter article, the X server is started on the same virtual console that you log in to, otherwise systemd can not keep track of the user session. You can then simply remove {{ic|ck-launch-session}} from your {{ic|~/.xinitrc}}.<br />
<br />
In order to check the status of your user session, you can use {{ic|loginctl}}. To see if your user session is properly set up, check if the following command contains {{ic|1=Active=yes}}. All {{Pkg|polkit}} actions like suspending the system or mounting external drives with [[Udisks]] should then work automatically.<br />
$ loginctl show-session <session-id><br />
<br />
{{Note|If you use [[NetworkManager]], you have to recompile it with systemd support from the [[ABS]] by setting {{ic|1=--with-session-tracking=systemd}} in the [[PKGBUILD]].}}<br />
<br />
== Troubleshooting ==<br />
=== Shutdown/Reboot takes terribly long ===<br />
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. systemd waits some time for each service to exit before trying to kill it.<br />
To find out if you are affected see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
==== SLiM and xfce-session ====<br />
One setup that can produce a shutdown freeze is Xfce in conjunction with SLiM: Shutting down/rebooting using xfce-session will cause slim.service to hang for half a minute until systemd kills it the hard way.<br />
One workaround is to create a modified {{ic|slim.service}}:<br />
{{hc|/etc/systemd/system/slim.service|<nowiki><br />
[Unit]<br />
Description=SLiM Simple Login Manager<br />
After=systemd-user-sessions.service<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/var/lock/slim.lock<br />
ExecStart=/usr/bin/slim -d<br />
ExecStop=/bin/kill -9 $MAINPID<br />
ExecStopPost=/bin/rm /var/lock/slim.lock<br />
<br />
[Install]<br />
WantedBy=graphical.target</nowiki>}}<br />
This causes SLiM to be terminated using SIGKILL. Since the lock file is also removed this does not cause a problem.<br />
<br />
=== If some services are failing to start ===<br />
<br />
If your {{ic|/var/tmp}} is a symbolic link to {{ic|/tmp}}, expect some services to fail when started via systemd. In these cases, the failure status of the processes (via {{ic|systemctl status <service>}}) will be "226/NAMESPACE". To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{pkg|filesystem}} package.<br />
<br />
=== Disable warning bell ===<br />
Add command {{ic|xset -b}} to the {{ic|.xinitrc}} file.<br />
Discussion on [https://bbs.archlinux.org/viewtopic.php?pid=1148781 this] forum topic.<br />
<br />
== See also==<br />
*[http://www.freedesktop.org/wiki/Software/systemd Official Web Site]<br />
*[http://0pointer.de/public/systemd-man/ Manual Pages]<br />
*[http://freedesktop.org/wiki/Software/systemd/Optimizations systemd Optimizations]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]<br />
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks]<br />
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]<br />
*[http://fedoraproject.org/wiki/Systemd About systemd on Fedora Project]<br />
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems How to debug Systemd problems]<br />
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Booting up: Tools and tips for systemd, a Linux init tool. In The H]<br />
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]<br />
*[http://0pointer.de/blog/projects/systemd-update.html status update]<br />
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]<br />
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]<br />
*[http://0pointer.de/blog/projects/why.html most recent summary]</div>Kopfweh