https://wiki.archlinux.org/api.php?action=feedcontributions&user=Imatechguy&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:14:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd&diff=228108Systemd2012-10-11T00:50:27Z<p>Imatechguy: /* Supplementary information */</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 />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<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=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and sysvinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration formats (there should be warnings at boot) to the [[#Native systemd configuration files|native systemd configuration files]], and reboot to verify that this works as expected with initscripts.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively. If the legacy support for DAEMONS in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
{{Warning|In case you have daemons in the DAEMONS array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
=== A mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents.<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation<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]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so systemd will start the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== A pure systemd installation ===<br />
<br />
Lastly, it is possible to remove initscripts and sysvinit entirely and only use systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove the initscripts package from your system.<br />
<br />
=== Supplementary information ===<br />
<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
<br />
{{Tip|If you intend to use a static ip in a pure sytemd environment without ''netcfg'' or ''networkmanager'' Take care not to use the -s option with pacman when removing initscripts as it will also remove the ''iproute2'' package if it is not a dependency of another installed package. ''iproute2'' must remain installed.}}<br />
<br />
== Native systemd configuration files ==<br />
<br />
{{Note|You may need to create these files.}}<br />
<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 />
<br />
=== Hostname ===<br />
<br />
{{hc|/etc/hostname|<br />
myhostname}}<br />
<br />
=== Console and keymap ===<br />
<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<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 with systemd 193 or older, use:<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=<br />
FONT=}}<br />
}}<br />
<br />
=== Locale ===<br />
<br />
Read {{ic|man locale.conf}} for more options:<br />
<br />
{{hc|/etc/locale.conf|2=<br />
LANG=en_US.UTF-8}}<br />
<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
<br />
Read {{ic|man 5 localtime}} for more options.<br />
<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
<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.<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 />
<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 />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
<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 />
<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 />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<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 />
<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 />
<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 />
<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
<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 />
<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 its 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 />
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 these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Note|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. 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 concurrently 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 />
<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 />
=== Hibernation ===<br />
{{Merge|pm-utils|uswsusp-git is just one of the backend that pm-utils supports. Other backend also work.}}<br />
To hibernate your system a.k.a ''Suspend To Disk'' with {{ic|sytemctl hibernate}}, First install [https://aur.archlinux.org/packages.php?ID=44473/ uswsusp-git] from [https://wiki.archlinux.org/index.php/AUR/ AUR] and configure according to the instructions mentioned [[Uswsusp|here]]. Now do :<br />
<br />
# cp /usr/lib/systemd/system/systemd-hibernate.service /etc/systemd/system/<br />
# cd /etc/systemd/system/<br />
<br />
Open {{ic|systemd-hibernate.service}} with your prefered text editor <br />
# vim systemd-hibernate.service<br />
and edit the line from this :<br />
<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/lib/systemd/systemd-sleep hibernate<br />
</nowiki>}}<br />
to this :<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/sbin/s2disk<br />
</nowiki>}}<br />
<br />
After that execute {{ic|systemctl hibernate}} to hibernate your system.<br />
<br />
=== Unit ===<br />
<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 />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ 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 />
<br />
$ 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 />
<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 />
<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 />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note| If services do not have an {{ic|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 {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ 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 />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Hibernate the system:<br />
<br />
$ systemctl hibernate<br />
<br />
== Runlevels/targets ==<br />
<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 />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
# systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<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 />
<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 />
<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<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 />
<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 />
<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 />
<br />
# 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 />
<br />
[Install]<br />
Alias=default.target<br />
<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 />
<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 />
# 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|<br />
/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 />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using service file ===<br />
<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 />
<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|2=<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 />
<br />
== Systemd Journal ==<br />
<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 />
<br />
# journalctl<br />
<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 />
<br />
# 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 />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# 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 />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with a classic syslog daemon ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. 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 />
<br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};<br />
<br />
and enable syslog-ng:<br />
<br />
# systemctl enable syslog-ng.service<br />
<br />
== Network ==<br />
<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
<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 />
<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
Sometimes the dhcpd service starts before your network card module ({{bug|30235}}), manually add your network card to {{ic|/etc/modules-load.d/****.conf}}. Example: create {{ic|/etc/modules-load.d/r8169.conf}}, this is a Realtek card:<br />
<br />
# r8169<br />
<br />
=== Other configurations ===<br />
<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 />
<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 />
<br />
=== Initscripts emulation ===<br />
<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 />
<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 />
<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 />
<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 />
<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 />
<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}}, run:<br />
<br />
# systemctl enable <service_name>.service<br />
<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 />
<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 />
<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 />
<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 />
<br />
=== Handling dependencies ===<br />
<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 />
<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 />
<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 />
<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 />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<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 />
<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 />
<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 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 />
# 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<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 />
# 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<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only one 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 />
{{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 />
{{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 />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>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<nowiki>|</nowiki>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 />
<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 />
<br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=<br />
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 />
<br />
$ systemctl poweroff<br />
<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:<br />
<br />
{{bc|# systemctl enable dmraid.service}}}}<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 />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Then:<br />
<br />
# systemctl enable ''myscript''.service<br />
<br />
This example assumes you want your script to start up when the target multi-user is launched.}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal. 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 />
<br />
{{bc|# iptables --list}}}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=This happens when using {{ic|systemctl enable}} and the symlink it tries to create in {{ic|/etc/systemd/system/}} already exists. Typically this happens when switching from one display manager to another one (for instance GDM to KDM, which can be enabled with {{ic|gdm.service}} and {{ic|kdm.service}}, respectively) and the corresponding symlink {{ic|/etc/systemd/system/display-manager.service}} already exists.<br />
<br />
To solve this problem, use {{ic|systemctl -f enable}} to overwrite an existing symlink.}}<br />
<br />
== Optimization ==<br />
<br />
=== systemd-analyze ===<br />
<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 />
<br />
$ systemd-analyze<br />
<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 />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Enabling bootchart in conjunction with systemd ====<br />
<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 />
<br />
# systemctl enable bootchart.service<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
<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 />
alias start='sudo rc.d start'<br />
alias restart='sudo rc.d restart'<br />
alias stop='sudo rc.d stop'<br />
else<br />
alias start='sudo systemctl start'<br />
alias restart='sudo systemctl restart'<br />
alias stop='sudo systemctl stop'<br />
alias enable='sudo systemctl enable'<br />
alias status='sudo systemctl status'<br />
alias disable='sudo systemctl disable'<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
<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 />
<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 />
# 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 />
<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 />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
<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 />
# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service<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 />
<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 />
<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 />
<br />
=== Shutdown/Reboot takes terribly long ===<br />
<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. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
==== SLiM and xfce-session ====<br />
<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 />
<br />
{{hc|/etc/systemd/system/slim.service|2=<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}}<br />
<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 {{ic|"226/NAMESPACE"}}. To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{Pkg|filesystem}} package.<br />
<br />
== See also ==<br />
<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>Imatechguyhttps://wiki.archlinux.org/index.php?title=Systemd&diff=228107Systemd2012-10-11T00:41:55Z<p>Imatechguy: /* Supplementary information */</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 />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<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=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and sysvinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration formats (there should be warnings at boot) to the [[#Native systemd configuration files|native systemd configuration files]], and reboot to verify that this works as expected with initscripts.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively. If the legacy support for DAEMONS in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
{{Warning|In case you have daemons in the DAEMONS array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
=== A mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents.<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation<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]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so systemd will start the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== A pure systemd installation ===<br />
<br />
Lastly, it is possible to remove initscripts and sysvinit entirely and only use systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove the initscripts package from your system.<br />
<br />
=== Supplementary information ===<br />
<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
<br />
{{Tip|If you intend to use a static ip in a pure sytemd environment without [http://www.archlinux.org/packages/core/any/netcfg/ netcfg] or [http://www.archlinux.org/packages/extra/x86_64/networkmanager/ networkmanager] Take care not to use the -s option with [https://wiki.archlinux.org/index.php/Pacman pacman] when removing initscripts as it will also remove the [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] package if [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] is not a dependency of another installed package. The [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] package must remain installed.}}<br />
<br />
== Native systemd configuration files ==<br />
<br />
{{Note|You may need to create these files.}}<br />
<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 />
<br />
=== Hostname ===<br />
<br />
{{hc|/etc/hostname|<br />
myhostname}}<br />
<br />
=== Console and keymap ===<br />
<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<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 with systemd 193 or older, use:<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=<br />
FONT=}}<br />
}}<br />
<br />
=== Locale ===<br />
<br />
Read {{ic|man locale.conf}} for more options:<br />
<br />
{{hc|/etc/locale.conf|2=<br />
LANG=en_US.UTF-8}}<br />
<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
<br />
Read {{ic|man 5 localtime}} for more options.<br />
<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
<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.<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 />
<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 />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
<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 />
<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 />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<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 />
<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 />
<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 />
<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
<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 />
<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 its 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 />
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 these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Note|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. 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 concurrently 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 />
<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 />
=== Hibernation ===<br />
{{Merge|pm-utils|uswsusp-git is just one of the backend that pm-utils supports. Other backend also work.}}<br />
To hibernate your system a.k.a ''Suspend To Disk'' with {{ic|sytemctl hibernate}}, First install [https://aur.archlinux.org/packages.php?ID=44473/ uswsusp-git] from [https://wiki.archlinux.org/index.php/AUR/ AUR] and configure according to the instructions mentioned [[Uswsusp|here]]. Now do :<br />
<br />
# cp /usr/lib/systemd/system/systemd-hibernate.service /etc/systemd/system/<br />
# cd /etc/systemd/system/<br />
<br />
Open {{ic|systemd-hibernate.service}} with your prefered text editor <br />
# vim systemd-hibernate.service<br />
and edit the line from this :<br />
<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/lib/systemd/systemd-sleep hibernate<br />
</nowiki>}}<br />
to this :<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/sbin/s2disk<br />
</nowiki>}}<br />
<br />
After that execute {{ic|systemctl hibernate}} to hibernate your system.<br />
<br />
=== Unit ===<br />
<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 />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ 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 />
<br />
$ 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 />
<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 />
<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 />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note| If services do not have an {{ic|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 {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ 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 />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Hibernate the system:<br />
<br />
$ systemctl hibernate<br />
<br />
== Runlevels/targets ==<br />
<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 />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
# systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<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 />
<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 />
<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<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 />
<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 />
<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 />
<br />
# 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 />
<br />
[Install]<br />
Alias=default.target<br />
<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 />
<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 />
# 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|<br />
/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 />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using service file ===<br />
<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 />
<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|2=<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 />
<br />
== Systemd Journal ==<br />
<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 />
<br />
# journalctl<br />
<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 />
<br />
# 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 />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# 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 />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with a classic syslog daemon ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. 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 />
<br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};<br />
<br />
and enable syslog-ng:<br />
<br />
# systemctl enable syslog-ng.service<br />
<br />
== Network ==<br />
<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
<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 />
<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
Sometimes the dhcpd service starts before your network card module ({{bug|30235}}), manually add your network card to {{ic|/etc/modules-load.d/****.conf}}. Example: create {{ic|/etc/modules-load.d/r8169.conf}}, this is a Realtek card:<br />
<br />
# r8169<br />
<br />
=== Other configurations ===<br />
<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 />
<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 />
<br />
=== Initscripts emulation ===<br />
<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 />
<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 />
<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 />
<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 />
<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 />
<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}}, run:<br />
<br />
# systemctl enable <service_name>.service<br />
<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 />
<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 />
<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 />
<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 />
<br />
=== Handling dependencies ===<br />
<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 />
<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 />
<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 />
<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 />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<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 />
<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 />
<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 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 />
# 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<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 />
# 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<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only one 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 />
{{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 />
{{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 />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>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<nowiki>|</nowiki>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 />
<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 />
<br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=<br />
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 />
<br />
$ systemctl poweroff<br />
<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:<br />
<br />
{{bc|# systemctl enable dmraid.service}}}}<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 />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Then:<br />
<br />
# systemctl enable ''myscript''.service<br />
<br />
This example assumes you want your script to start up when the target multi-user is launched.}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal. 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 />
<br />
{{bc|# iptables --list}}}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=This happens when using {{ic|systemctl enable}} and the symlink it tries to create in {{ic|/etc/systemd/system/}} already exists. Typically this happens when switching from one display manager to another one (for instance GDM to KDM, which can be enabled with {{ic|gdm.service}} and {{ic|kdm.service}}, respectively) and the corresponding symlink {{ic|/etc/systemd/system/display-manager.service}} already exists.<br />
<br />
To solve this problem, use {{ic|systemctl -f enable}} to overwrite an existing symlink.}}<br />
<br />
== Optimization ==<br />
<br />
=== systemd-analyze ===<br />
<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 />
<br />
$ systemd-analyze<br />
<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 />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Enabling bootchart in conjunction with systemd ====<br />
<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 />
<br />
# systemctl enable bootchart.service<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
<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 />
alias start='sudo rc.d start'<br />
alias restart='sudo rc.d restart'<br />
alias stop='sudo rc.d stop'<br />
else<br />
alias start='sudo systemctl start'<br />
alias restart='sudo systemctl restart'<br />
alias stop='sudo systemctl stop'<br />
alias enable='sudo systemctl enable'<br />
alias status='sudo systemctl status'<br />
alias disable='sudo systemctl disable'<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
<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 />
<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 />
# 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 />
<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 />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
<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 />
# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service<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 />
<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 />
<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 />
<br />
=== Shutdown/Reboot takes terribly long ===<br />
<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. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
==== SLiM and xfce-session ====<br />
<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 />
<br />
{{hc|/etc/systemd/system/slim.service|2=<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}}<br />
<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 {{ic|"226/NAMESPACE"}}. To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{Pkg|filesystem}} package.<br />
<br />
== See also ==<br />
<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>Imatechguyhttps://wiki.archlinux.org/index.php?title=Systemd&diff=228106Systemd2012-10-11T00:40:36Z<p>Imatechguy: /* Supplementary information */</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 />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<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=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and sysvinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration formats (there should be warnings at boot) to the [[#Native systemd configuration files|native systemd configuration files]], and reboot to verify that this works as expected with initscripts.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively. If the legacy support for DAEMONS in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
{{Warning|In case you have daemons in the DAEMONS array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
=== A mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents.<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation<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]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so systemd will start the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== A pure systemd installation ===<br />
<br />
Lastly, it is possible to remove initscripts and sysvinit entirely and only use systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove the initscripts package from your system.<br />
<br />
=== Supplementary information ===<br />
<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
<br />
{{Tip|If you intend to use a static ip in a pure sytemd environment without [http://www.archlinux.org/packages/core/any/netcfg/ netcfg] or [http://www.archlinux.org/packages/extra/x86_64/networkmanager/ networkmanager] Take care not to use the -s option with [https://wiki.archlinux.org/index.php/Pacman pacman] when removing initscripts as it may also remove the [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] package if [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] is not a dependency of another installed package.}}<br />
<br />
== Native systemd configuration files ==<br />
<br />
{{Note|You may need to create these files.}}<br />
<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 />
<br />
=== Hostname ===<br />
<br />
{{hc|/etc/hostname|<br />
myhostname}}<br />
<br />
=== Console and keymap ===<br />
<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<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 with systemd 193 or older, use:<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=<br />
FONT=}}<br />
}}<br />
<br />
=== Locale ===<br />
<br />
Read {{ic|man locale.conf}} for more options:<br />
<br />
{{hc|/etc/locale.conf|2=<br />
LANG=en_US.UTF-8}}<br />
<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
<br />
Read {{ic|man 5 localtime}} for more options.<br />
<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
<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.<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 />
<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 />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
<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 />
<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 />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<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 />
<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 />
<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 />
<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
<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 />
<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 its 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 />
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 these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Note|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. 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 concurrently 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 />
<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 />
=== Hibernation ===<br />
{{Merge|pm-utils|uswsusp-git is just one of the backend that pm-utils supports. Other backend also work.}}<br />
To hibernate your system a.k.a ''Suspend To Disk'' with {{ic|sytemctl hibernate}}, First install [https://aur.archlinux.org/packages.php?ID=44473/ uswsusp-git] from [https://wiki.archlinux.org/index.php/AUR/ AUR] and configure according to the instructions mentioned [[Uswsusp|here]]. Now do :<br />
<br />
# cp /usr/lib/systemd/system/systemd-hibernate.service /etc/systemd/system/<br />
# cd /etc/systemd/system/<br />
<br />
Open {{ic|systemd-hibernate.service}} with your prefered text editor <br />
# vim systemd-hibernate.service<br />
and edit the line from this :<br />
<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/lib/systemd/systemd-sleep hibernate<br />
</nowiki>}}<br />
to this :<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/sbin/s2disk<br />
</nowiki>}}<br />
<br />
After that execute {{ic|systemctl hibernate}} to hibernate your system.<br />
<br />
=== Unit ===<br />
<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 />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ 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 />
<br />
$ 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 />
<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 />
<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 />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note| If services do not have an {{ic|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 {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ 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 />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Hibernate the system:<br />
<br />
$ systemctl hibernate<br />
<br />
== Runlevels/targets ==<br />
<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 />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
# systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<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 />
<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 />
<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<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 />
<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 />
<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 />
<br />
# 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 />
<br />
[Install]<br />
Alias=default.target<br />
<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 />
<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 />
# 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|<br />
/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 />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using service file ===<br />
<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 />
<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|2=<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 />
<br />
== Systemd Journal ==<br />
<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 />
<br />
# journalctl<br />
<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 />
<br />
# 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 />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# 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 />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with a classic syslog daemon ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. 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 />
<br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};<br />
<br />
and enable syslog-ng:<br />
<br />
# systemctl enable syslog-ng.service<br />
<br />
== Network ==<br />
<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
<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 />
<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
Sometimes the dhcpd service starts before your network card module ({{bug|30235}}), manually add your network card to {{ic|/etc/modules-load.d/****.conf}}. Example: create {{ic|/etc/modules-load.d/r8169.conf}}, this is a Realtek card:<br />
<br />
# r8169<br />
<br />
=== Other configurations ===<br />
<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 />
<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 />
<br />
=== Initscripts emulation ===<br />
<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 />
<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 />
<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 />
<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 />
<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 />
<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}}, run:<br />
<br />
# systemctl enable <service_name>.service<br />
<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 />
<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 />
<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 />
<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 />
<br />
=== Handling dependencies ===<br />
<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 />
<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 />
<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 />
<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 />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<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 />
<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 />
<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 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 />
# 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<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 />
# 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<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only one 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 />
{{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 />
{{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 />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>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<nowiki>|</nowiki>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 />
<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 />
<br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=<br />
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 />
<br />
$ systemctl poweroff<br />
<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:<br />
<br />
{{bc|# systemctl enable dmraid.service}}}}<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 />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Then:<br />
<br />
# systemctl enable ''myscript''.service<br />
<br />
This example assumes you want your script to start up when the target multi-user is launched.}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal. 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 />
<br />
{{bc|# iptables --list}}}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=This happens when using {{ic|systemctl enable}} and the symlink it tries to create in {{ic|/etc/systemd/system/}} already exists. Typically this happens when switching from one display manager to another one (for instance GDM to KDM, which can be enabled with {{ic|gdm.service}} and {{ic|kdm.service}}, respectively) and the corresponding symlink {{ic|/etc/systemd/system/display-manager.service}} already exists.<br />
<br />
To solve this problem, use {{ic|systemctl -f enable}} to overwrite an existing symlink.}}<br />
<br />
== Optimization ==<br />
<br />
=== systemd-analyze ===<br />
<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 />
<br />
$ systemd-analyze<br />
<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 />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Enabling bootchart in conjunction with systemd ====<br />
<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 />
<br />
# systemctl enable bootchart.service<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
<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 />
alias start='sudo rc.d start'<br />
alias restart='sudo rc.d restart'<br />
alias stop='sudo rc.d stop'<br />
else<br />
alias start='sudo systemctl start'<br />
alias restart='sudo systemctl restart'<br />
alias stop='sudo systemctl stop'<br />
alias enable='sudo systemctl enable'<br />
alias status='sudo systemctl status'<br />
alias disable='sudo systemctl disable'<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
<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 />
<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 />
# 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 />
<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 />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
<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 />
# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service<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 />
<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 />
<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 />
<br />
=== Shutdown/Reboot takes terribly long ===<br />
<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. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
==== SLiM and xfce-session ====<br />
<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 />
<br />
{{hc|/etc/systemd/system/slim.service|2=<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}}<br />
<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 {{ic|"226/NAMESPACE"}}. To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{Pkg|filesystem}} package.<br />
<br />
== See also ==<br />
<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>Imatechguyhttps://wiki.archlinux.org/index.php?title=Systemd&diff=228105Systemd2012-10-11T00:40:07Z<p>Imatechguy: /* Supplementary information */</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 />
* While systemd can replace some of the functionality of '''cron''', '''acpid''', or '''xinetd''', there is no need to switch away from using the traditional daemons unless you want to.<br />
<br />
== Installation ==<br />
<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=/usr/lib/systemd/systemd}} [[kernel parameters|kernel parameter]].<br />
<br />
=== A mixed systemd/sysvinit/initscripts installation ===<br />
<br />
It is possible to keep systemd and sysvinit both installed and using the same configuration files so you can move back and forth between them freely:<br />
<br />
# Move away from the deprecated initscripts configuration formats (there should be warnings at boot) to the [[#Native systemd configuration files|native systemd configuration files]], and reboot to verify that this works as expected with initscripts.<br />
# Install {{Pkg|systemd}} from the [[Official Repositories|official repositories]].<br />
# Add {{ic|1=init=/usr/lib/systemd/systemd}} to the [[Kernel parameters|kernel parameters]] in your bootloader.<br />
# Reboot.<br />
<br />
Systemd will start the daemons listed in {{ic|/etc/rc.conf}} and run {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} on boot/shutdown respectively. If the legacy support for DAEMONS in {{ic|rc.conf}} or the scripts in {{ic|rc.local}} is not needed, the corresponding service files can be masked to disable them.<br />
<br />
{{Warning|In case you have daemons in the DAEMONS array which have native systemd service files, the native service files will be used automatically. However, if the names of the rc script and the systemd service file do not match, this will not work and you should make sure that only one of the two (preferably the native one) is enabled.}}<br />
<br />
=== A mixed systemd/initscripts installation ===<br />
<br />
It is possible to replace sysvinit with systemd, but keep initscripts around in case there are some rc scripts which do not yet have systemd equivalents.<br />
<br />
# Follow the instructions for a mixed systemd/sysvinit/initscripts installation<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]]. Daemons that do not yet have equivalent systemd service files should be kept in the DAEMONS array so systemd will start the legacy rc scripts.<br />
# Install {{Pkg|systemd-sysvcompat}}. This conflicts with {{Pkg|sysvinit}}, and will prompt you to remove it.<br />
# Remove the {{ic|1=init=...}} entry as {{ic|/sbin/init}} is now a symlink to systemd.<br />
# Reboot.<br />
<br />
The only difference between this and the keeping sysvinit around is that all the sysvinit binaries are replaced by symlinks to systemctl. However, the functionality should be unchanged.<br />
<br />
=== A pure systemd installation ===<br />
<br />
Lastly, it is possible to remove initscripts and sysvinit entirely and only use systemd.<br />
<br />
# Follow the instructions for a mixed systemd/initscripts installation<br />
# Make sure there are no longer any daemons being started by the DAEMONS array in {{ic|/etc/rc.conf}} and that {{ic|/etc/rc.local}} and {{ic|/etc/rc.local.shutdown}} are both empty.<br />
# Remove the initscripts package from your system.<br />
<br />
=== Supplementary information ===<br />
<br />
{{Tip|If you have {{ic|quiet}} in your kernel parameters, you might want to remove it for your first couple of systemd boots, to assist with identifying any issues during boot.}}<br />
<br />
{{Tip|If you intend to use a static ip without [http://www.archlinux.org/packages/core/any/netcfg/ netcfg] or [http://www.archlinux.org/packages/extra/x86_64/networkmanager/ networkmanager] Take care not to use the -s option with [https://wiki.archlinux.org/index.php/Pacman pacman] when removing initscripts as it may also remove the [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] package if [http://www.archlinux.org/packages/core/i686/iproute2/ iproute2] is not a dependency of another installed package.}}<br />
<br />
== Native systemd configuration files ==<br />
<br />
{{Note|You may need to create these files.}}<br />
<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 />
<br />
=== Hostname ===<br />
<br />
{{hc|/etc/hostname|<br />
myhostname}}<br />
<br />
=== Console and keymap ===<br />
<br />
The {{ic|/etc/vconsole.conf}} file configures the virtual console, i.e. keyboard mapping and console font.<br />
<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=us<br />
FONT=lat9w-16<br />
FONT_MAP=8859-1_to_uni}}<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 with systemd 193 or older, use:<br />
{{hc|/etc/vconsole.conf|2=<br />
KEYMAP=<br />
FONT=}}<br />
}}<br />
<br />
=== Locale ===<br />
<br />
Read {{ic|man locale.conf}} for more options:<br />
<br />
{{hc|/etc/locale.conf|2=<br />
LANG=en_US.UTF-8}}<br />
<br />
For more info see [[Locale]].<br />
<br />
=== Time zone ===<br />
<br />
Read {{ic|man 5 localtime}} for more options.<br />
<br />
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime<br />
<br />
{{Note|{{ic|/etc/timezone}} has been deprecated in {{ic|systemd-190}} and can/should be deleted.}}<br />
<br />
=== Hardware clock time ===<br />
<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.<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 />
<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 />
<br />
{{hc|/etc/modules-load.d/virtio-net.conf|<br />
# Load virtio-net.ko at boot<br />
virtio-net}}<br />
<br />
See also [[Modprobe#Options]].<br />
<br />
=== Kernel modules blacklist ===<br />
<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 />
<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 />
<br />
{{hc|/usr/lib/tmpfiles.d/samba.conf|<br />
D /var/run/samba 0755 root root}}<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 />
<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 />
<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 />
<br />
Systemd handles some power-related ACPI events. This is configured via the following options in {{ic|/etc/systemd/logind.conf}}:<br />
<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 />
<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 its 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 />
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 these inhibits are not taken, you can end up with a situation where systemd suspends your system, then when it wakes up the other power manager suspends it again.<br />
<br />
{{Note|Currently, the power manager in newest version of [[KDE]] is the only one that issues the necessary "inhibited" commands. Until the others do, you will need to set the {{ic|Handle}} options to {{ic|ignore}} if you want your ACPI events to be handled by [[GNOME]], [[Xfce]], [[acpid]] or other programs. 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 concurrently 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 />
<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 />
=== Hibernation ===<br />
{{Merge|pm-utils|uswsusp-git is just one of the backend that pm-utils supports. Other backend also work.}}<br />
To hibernate your system a.k.a ''Suspend To Disk'' with {{ic|sytemctl hibernate}}, First install [https://aur.archlinux.org/packages.php?ID=44473/ uswsusp-git] from [https://wiki.archlinux.org/index.php/AUR/ AUR] and configure according to the instructions mentioned [[Uswsusp|here]]. Now do :<br />
<br />
# cp /usr/lib/systemd/system/systemd-hibernate.service /etc/systemd/system/<br />
# cd /etc/systemd/system/<br />
<br />
Open {{ic|systemd-hibernate.service}} with your prefered text editor <br />
# vim systemd-hibernate.service<br />
and edit the line from this :<br />
<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/lib/systemd/systemd-sleep hibernate<br />
</nowiki>}}<br />
to this :<br />
{{hc|/etc/systemd/system/systemd-hibernate.service|<nowiki><br />
...<br />
ExecStart=/usr/sbin/s2disk<br />
</nowiki>}}<br />
<br />
After that execute {{ic|systemctl hibernate}} to hibernate your system.<br />
<br />
=== Unit ===<br />
<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 />
$ systemctl<br />
<br />
or:<br />
<br />
$ systemctl list-units<br />
<br />
List failed units:<br />
<br />
$ 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 />
<br />
$ 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 />
<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 />
<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 />
# systemctl start <unit><br />
<br />
Deactivate a unit immediately:<br />
<br />
# systemctl stop <unit><br />
<br />
Restart a unit:<br />
<br />
# systemctl restart <unit><br />
<br />
Ask a unit to reload its configuration:<br />
<br />
# systemctl reload <unit><br />
<br />
Show the status of a unit, including whether it is running or not:<br />
<br />
$ systemctl status <unit><br />
<br />
Check whether a unit is already enabled or not:<br />
<br />
$ systemctl is-enabled <unit><br />
<br />
Enable a unit to be started on bootup:<br />
<br />
# systemctl enable <unit><br />
<br />
{{Note| If services do not have an {{ic|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 {{ic|foo}} with the name of the service.<br />
# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/<br />
}}<br />
<br />
Disable a unit to not start during bootup:<br />
<br />
# systemctl disable <unit><br />
<br />
Show the manual page associated with a unit (this has to be supported by the unit file):<br />
<br />
$ 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 />
$ systemctl reboot<br />
<br />
Shut down and power-off the system:<br />
<br />
$ systemctl poweroff<br />
<br />
Shut down and halt the system:<br />
<br />
$ systemctl halt<br />
<br />
Suspend the system:<br />
<br />
$ systemctl suspend<br />
<br />
Hibernate the system:<br />
<br />
$ systemctl hibernate<br />
<br />
== Runlevels/targets ==<br />
<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 />
<br />
The following should be used under systemd instead of {{ic|runlevel}}:<br />
<br />
# systemctl list-units --type=target<br />
<br />
=== Create custom target ===<br />
<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 />
<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 />
<br />
In systemd runlevels are exposed via "target units". You can change them like this:<br />
<br />
# systemctl isolate graphical.target<br />
<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 />
<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 />
<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 />
<br />
# 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 />
<br />
[Install]<br />
Alias=default.target<br />
<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 />
<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 />
# 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|<br />
/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 />
# rm /etc/systemd/system/default.target<br />
<br />
=== Using service file ===<br />
<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 />
<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|2=<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 />
<br />
== Systemd Journal ==<br />
<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 />
<br />
# journalctl<br />
<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 />
<br />
# 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 />
<br />
# journalctl /usr/lib/systemd/systemd<br />
<br />
Show all messages by a specific process:<br />
<br />
# journalctl _PID=1<br />
<br />
Show all messages by a specific unit:<br />
<br />
# 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 />
<br />
SystemMaxUse=50M<br />
<br />
Refer to {{ic|man journald.conf}} for more info.<br />
<br />
=== Journald in conjunction with a classic syslog daemon ===<br />
<br />
Compatibility with classic syslog implementations is provided via a socket {{ic|/run/systemd/journal/syslog}}, to which all messages are forwarded. 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 />
<br />
source src {<br />
unix-dgram("/run/systemd/journal/syslog");<br />
internal();<br />
file("/proc/kmsg");<br />
};<br />
<br />
and enable syslog-ng:<br />
<br />
# systemctl enable syslog-ng.service<br />
<br />
== Network ==<br />
<br />
=== Dynamic (DHCP) with dhcpcd ===<br />
<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 />
<br />
To enable DHCP for {{ic|eth0}}, simply use:<br />
<br />
# systemctl start dhcpcd@eth0.service<br />
<br />
You can enable the service to automatically start at boot with:<br />
<br />
# systemctl enable dhcpcd@eth0.service<br />
<br />
Sometimes the dhcpd service starts before your network card module ({{bug|30235}}), manually add your network card to {{ic|/etc/modules-load.d/****.conf}}. Example: create {{ic|/etc/modules-load.d/r8169.conf}}, this is a Realtek card:<br />
<br />
# r8169<br />
<br />
=== Other configurations ===<br />
<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 />
<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 />
<br />
=== Initscripts emulation ===<br />
<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 />
<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 />
<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 />
<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 />
<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 />
<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}}, run:<br />
<br />
# systemctl enable <service_name>.service<br />
<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 />
<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 />
<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 />
<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 />
<br />
=== Handling dependencies ===<br />
<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 />
<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 />
<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 />
<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 />
<br />
{{hc|/etc/systemd/system/<service-name>.service|2=<br />
.include /usr/lib/systemd/system/<service-name>.service<br />
<br />
[Unit]<br />
Requires=<new dependency><br />
After=<new dependency>}}<br />
<br />
Then run the following for your changes to take effect:<br />
<br />
# systemctl reenable <unit><br />
# systemctl restart <unit><br />
<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 />
<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 />
<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 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 />
# 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<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 />
# 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<br />
<br />
systemd does not use the {{ic|/etc/inittab}} file.<br />
<br />
{{Note|As of systemd 30, only one 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 />
{{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 />
{{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 />
CONFIG_AUDIT=y (recommended)<br />
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)<br />
CONFIG_CGROUPS=y<br />
CONFIG_IPV6=[y<nowiki>|</nowiki>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<nowiki>|</nowiki>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 />
<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 />
<br />
{{hc|$ systemctl show -p "Wants" multi-user.target|2=<br />
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 />
<br />
$ systemctl poweroff<br />
<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:<br />
<br />
{{bc|# systemctl enable dmraid.service}}}}<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 />
<br />
[Unit]<br />
Description=My script<br />
<br />
[Service]<br />
ExecStart=/usr/bin/my-script<br />
<br />
[Install]<br />
WantedBy=multi-user.target <br />
<br />
Then:<br />
<br />
# systemctl enable ''myscript''.service<br />
<br />
This example assumes you want your script to start up when the target multi-user is launched.}}<br />
<br />
{{FAQ<br />
|question=Status of .service says "active (exited)" in green. (e.g. iptables)<br />
|answer=This is perfectly normal. 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 />
<br />
{{bc|# iptables --list}}}}<br />
<br />
{{FAQ<br />
|question={{ic|Failed to issue method call: File exists}} error<br />
|answer=This happens when using {{ic|systemctl enable}} and the symlink it tries to create in {{ic|/etc/systemd/system/}} already exists. Typically this happens when switching from one display manager to another one (for instance GDM to KDM, which can be enabled with {{ic|gdm.service}} and {{ic|kdm.service}}, respectively) and the corresponding symlink {{ic|/etc/systemd/system/display-manager.service}} already exists.<br />
<br />
To solve this problem, use {{ic|systemctl -f enable}} to overwrite an existing symlink.}}<br />
<br />
== Optimization ==<br />
<br />
=== systemd-analyze ===<br />
<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 />
<br />
$ systemd-analyze<br />
<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 />
<br />
$ systemd-analyze blame<br />
<br />
You can also create a SVG file which describes your boot process grapically, similiar to [[Bootchart]]:<br />
<br />
$ systemd-analyze plot > plot.svg<br />
<br />
==== Enabling bootchart in conjunction with systemd ====<br />
<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 />
<br />
# systemctl enable bootchart.service<br />
<br />
Read the [https://github.com/mmeeks/bootchart bootchart documentation] for further details on using this version of bootchart.<br />
<br />
=== Shell Shortcuts ===<br />
<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 />
alias start='sudo rc.d start'<br />
alias restart='sudo rc.d restart'<br />
alias stop='sudo rc.d stop'<br />
else<br />
alias start='sudo systemctl start'<br />
alias restart='sudo systemctl restart'<br />
alias stop='sudo systemctl stop'<br />
alias enable='sudo systemctl enable'<br />
alias status='sudo systemctl status'<br />
alias disable='sudo systemctl disable'<br />
fi<br />
</nowiki>}}<br />
<br />
=== Less output ===<br />
<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 />
<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 />
# 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 />
<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 />
<br />
{{hc|/etc/crypttab|<br />
data /dev/md0 /root/key noauto}}<br />
<br />
=== Readahead ===<br />
<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 />
# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service<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 />
<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 />
<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 />
<br />
=== Shutdown/Reboot takes terribly long ===<br />
<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. To find out if you are affected, see [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].<br />
<br />
==== SLiM and xfce-session ====<br />
<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 />
<br />
{{hc|/etc/systemd/system/slim.service|2=<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}}<br />
<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 {{ic|"226/NAMESPACE"}}. To overcome this blocker, simply remove your {{ic|/var/tmp}} symlink and reinstall the {{Pkg|filesystem}} package.<br />
<br />
== See also ==<br />
<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>Imatechguyhttps://wiki.archlinux.org/index.php?title=Talk:Systemd&diff=228104Talk:Systemd2012-10-11T00:30:56Z<p>Imatechguy: </p>
<hr />
<div>== Lack of internet connection using static ip address without netcfg or NetworkManager ==<br />
<br />
See [[https://wiki.archlinux.org/index.php/Systemd#A_pure_systemd_installation A pure systemd installation]] it instructs to remove the initscripts package. When doing so take care not to use the -s option of pacman with -R as it removes the iproute2 package also unless you have another package with iproute2 as a dependency.<br />
<br />
Safe:<br />
pacman -R initscripts<br />
<br />
pacman -Rn initscripts<br />
<br />
<br />
Not safe when iproute2 will also be removed:<br />
pacman -Rs initscripts <br />
<br />
pacman -Rns initscripts<br />
<br />
-- [[User:imatechguy|imatechguy]] ([[User talk:imatechguy|talk]]) 00:28, 11 Oct 2012 (UTC)<br />
<br />
== initrd usage ==<br />
<br />
If you are using an initrd without the {{ic|udev}} hook, mounting of additional LVM partitions will fail during boot. Add {{ic|udev}} to your mkinitcpio hooks and rebuild the initrd.<br><br />
-- [[User:Ronnyyy|Ronnyyy]] ([[User talk:Ronnyyy|talk]]) 19:50, 6 June 2012 (UTC)<br />
<br />
== Display manager fails to load with fast SSD ==<br />
<br />
I was having a problem with my display manager (LXDM) not loading on my laptop, which has a Sandisk Extreme SSD.<br />
Xorg.log would show errors like "No screens found."<br />
<br />
I eventually figured out that the problem was that my computer was booting so fast that KMS didn't have enough time to kick in before X was started. I solved by adding the KMS driver (i915 in my case) to the initramfs.<br />
<br />
Just a tip for SSD users, not sure if it should be added to the page or not.<br> --[[User:Steev|Steev]] ([[User talk:Steev|talk]]) 16:59, 2 September 2012 (UTC)<br />
* This is a general problem that needs to be solved in the display manager. GDM already implements the bits for the [http://cgit.freedesktop.org/systemd/systemd/commit/?id=f1a8e221ecacea23 CanGraphical] flag.<br />
:-- [[User:Falconindy|Falconindy]] ([[User talk:Falconindy|talk]]) 21:34, 2 September 2012 (UTC)<br />
<br />
== Confusion in new Installation section ==<br />
See [[https://wiki.archlinux.org/index.php/Systemd#A_mixed_systemd.2Finitscripts_installation mixed systemd/initscripts]] which teaches that to run a mixed systemd/initscripts setup, one should install '''systemd-sysvcompat''' but doing this will remove initscripts.<br />
<br />
% sudo pacman -S systemd-sysvcompat<br />
resolving dependencies...<br />
looking for inter-conflicts...<br />
:: systemd-sysvcompat and sysvinit are in conflict. Remove sysvinit? [y/N] y<br />
:: systemd-sysvcompat and initscripts are in conflict. Remove initscripts? [y/N] n<br />
error: unresolvable package conflicts detected<br />
error: failed to prepare transaction (conflicting dependencies)<br />
:: systemd-sysvcompat and initscripts are in conflict<br />
<br />
[[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 09:28, 3 October 2012 (UTC)<br />
<br />
== Hibernation with Systemd ==<br />
<br />
The hibernation section should be considered a hack since Systemd does not directly handle the backend that handles power management. Systemd uses the Upower interface to handle such requests</div>Imatechguy