Systemd

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
m (References: Link correction)
(Man pages: add link to directives)
 
(17 intermediate revisions by 6 users not shown)
Line 9: Line 9:
  
 
http://0pointer.de/blog/projects/why.html
 
http://0pointer.de/blog/projects/why.html
 
== Introduction ==
 
 
systemd starts up and supervises the entire system and is based around the notion of ''units'' composed of a name and a type and matching a configuration file with the same name and type (e.g. a unit avahi.service has a configuration file with the same name and is a unit encapsulating the Avahi daemon). There are seven different types of units:
 
 
# <code>service</code>: these are the most obvious kind of unit: daemons that can be started, stopped, restarted, reloaded.
 
# <code>socket</code>: this unit encapsulates a socket in the file-system or on the Internet. systemd currently support AF_INET, AF_INET6, AF_UNIX sockets of the types stream, datagram, and sequential packet. It can also support classic FIFOs as transport. Each socket unit has a matching service unit, that is started if the first connection comes in on the socket or FIFO (e.g. nscd.socket starts nscd.service on an incoming connection).
 
# <code>device</code>: this unit encapsulates a device in the Linux device tree. If a device is marked for this via udev rules, it will be exposed as a device unit in systemd. Properties set with udev can be used as configuration source to set dependencies for device units.
 
# <code>mount</code>: this unit encapsulates a mount point in the file system hierarchy.
 
# <code>automount</code>: this unit type encapsulates an automount point in the file system hierarchy. Each automount unit has a matching mount unit, which is started (i.e. mounted) as soon as the automount directory is accessed.
 
# <code>target</code>: this unit type is used for logical grouping of units: instead of actually doing anything by itself it simply references other units, which thereby can be controlled together. (e.g. multi-user.target, which is a target that basically plays the role of run-level 5 on classic SysV system; or bluetooth.target which is requested as soon as a bluetooth dongle becomes available and which simply pulls in bluetooth related services that otherwise would not need to be started: bluetoothd and obexd and suchlike).
 
# <code>snapshot</code>: similar to target units snapshots do not actually do anything themselves and their only purpose is to reference other units.
 
  
 
== systemd documentation ==
 
== systemd documentation ==
Line 27: Line 15:
  
 
http://0pointer.de/blog/projects/systemd-docs.html
 
http://0pointer.de/blog/projects/systemd-docs.html
 
 
== systemd features ==
 
 
'''systemd''' provides the following:
 
 
* aggressive parallelization capabilities using socket: To speed up the entire boot and start more processes in parallel, systemd creates the listening sockets before actually starting the daemon, and then just passes the socket to it. All sockets for all daemons are created in one step in the init system, and then in a second step run all daemons at once. If a service needs another, and it is not fully started up, what will happen is that the connection is queued in the providing service and the client will potentially block on that single request. But only that one client will block and only on that one request. Also, dependencies between services no longer have to be configured to allow proper parallelized start-up: starting all sockets at once and a service needing another, it surely can connect to its socket.
 
 
* D-Bus activation for starting services: Using bus activation, a service can be started the first time it is accessed. Bus activation also gives the minimal per-request synchronisation needed for starting up the providers and the consumers of D-Bus services at the same time: starting a service at the same time as another, if one is quicker, than via the bus activation logic the D-Bus queues the request until the other manages to establish its service name.
 
 
* offers on-demand starting of daemons
 
 
* keeps track of processes using Linux [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Every executed process gets its own cgroup and it is very easy to configure systemd to place services in cgroups that have been configured externally, for example via the libcgroups utilities.
 
 
* supports snapshotting and restoring of the system state: Snapshots can be used to save/rollback the state of all services and units of the init system. Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
 
 
 
* maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the <code>comment=</code> fstab option you can even mark <code>/etc/fstab</code> entries to become systemd controlled automount points..
 
 
* implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using ''After''/''Before'', ''Requires'' and ''Wants'' options in the unit configuration files to fix the ordering how units are activated. ''Requires'' and ''Wants'', express a positive requirement dependency, either mandatory, or optional. There is ''Conflicts'' which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.
 
 
and:
 
 
* For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect <code>stdin/stdout/stderr</code> of services to <code>syslog</code>, <code>/dev/kmsg</code>, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
 
 
* The native configuration files use a syntax that closely follows the well-known <code>.desktop</code> files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
 
 
{{admon/note|systemadm |
 
There's a minimal UI, <code>systemadm</code> that allows to start/stop/introspect services.  It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala.  Do not use it for now unless you are a developer}}
 
 
(... and more advanced)
 
 
* Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.
 
 
* /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
 
 
* Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
 
 
* Compatibility, to a certain extent, with <code>/dev/initctl</code>. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
 
 
* Compatibility with <code>utmp</code> and <code>wtmp</code> (To an extent that is far more than healthy, given how crufty <code>utmp</code> and <code>wtmp</code> today are).
 
 
For all details view [http://0pointer.de/blog/projects/systemd.html A short list of other features] on the developer blog.
 
  
 
== Tools ==  
 
== Tools ==  
Line 74: Line 20:
 
* <code>systemctl</code>: used to introspect and control the state of the systemd system and service manager
 
* <code>systemctl</code>: used to introspect and control the state of the systemd system and service manager
 
* <code>systemd-cgls</code>: recursively shows the contents of the selected Linux control group hierarchy in a tree  
 
* <code>systemd-cgls</code>: recursively shows the contents of the selected Linux control group hierarchy in a tree  
* <code>systemadm</code>: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd.  Part of the systemd-gtk page.  This is a early version and needs more work.  Do not use it for now unless you are a developer.   
+
* <code>systemadm</code>: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd.  Part of the systemd-gtk package.  This is an early version and needs more work.  Do not use it for now unless you are a developer.   
  
 
View the man pages for more details.
 
View the man pages for more details.
Line 87: Line 33:
  
 
For details about these special systemd boot units, view the man <code>systemd.special</code> page.
 
For details about these special systemd boot units, view the man <code>systemd.special</code> page.
 
+
it scripts  
== What is the status of systemd in Fedora? ==
+
 
+
Fedora 14 featured it is a technology preview.  It is the default in Fedora 15 and above replacing Upstart. 
+
 
+
== Has all legacy System V init files been converted to systemd service files or equivalent? ==
+
 
+
Many of the core services (/lib/systemd/system has them and you can check status at http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) have been converted but not all of them yet.  The transition is planned for Fedora 16.  Details at http://fedoraproject.org/wiki/Features/SysVtoSystemd.  systemd is fully compatible with the legacy init scripts  
+
  
 
== What is the tool to manage services with systemd? ==
 
== What is the tool to manage services with systemd? ==
Line 110: Line 49:
 
Activates a service immediately:
 
Activates a service immediately:
  
<pre>  systemctl start foo.service </pre>     
+
<pre>  systemctl start foo </pre>     
  
 
Deactivates a service immediately:  
 
Deactivates a service immediately:  
  
<pre>  systemctl stop foo.service </pre>   
+
<pre>  systemctl stop foo </pre>   
  
 
Restarts a service:
 
Restarts a service:
  
<pre> systemctl restart foo.service </pre>  
+
<pre> systemctl restart foo </pre>  
  
 
Shows status of a service including whether it is running or not:
 
Shows status of a service including whether it is running or not:
  
<pre> systemctl status foo.service </pre>   
+
<pre> systemctl status foo </pre>   
  
 
Enables a service to be started on bootup:
 
Enables a service to be started on bootup:
  
<pre> systemctl enable foo.service </pre>  
+
<pre> systemctl enable foo </pre>  
  
 
Disables a service to not start during bootup:
 
Disables a service to not start during bootup:
  
<pre> systemctl disable foo.service </pre>  
+
<pre> systemctl disable foo </pre>  
  
Check whether a service is already enabled or not:
+
Prevent a service from starting dynamically or even manually unless unmasked:
  
<pre> systemctl is-enabled foo.service; echo $? </pre>
+
<pre> systemctl mask foo </pre>
 +
 
 +
Check whether a service is already enabled or not:
  
0 indicates that it is enabled, and 1 indicates that it is disabled. In Fedora 17, in addition to the return code, "enabled" or "disabled" will be printed to stdout.
+
<pre> systemctl is-enabled foo</pre>
  
 
Refer to man systemctl for more details.
 
Refer to man systemctl for more details.
  
== How do I change the runlevel? ==
+
== How do I change the target (runlevel) ? ==
  
 
systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.   
 
systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.   
Line 148: Line 89:
 
You can switch to 'runlevel 3' by running  
 
You can switch to 'runlevel 3' by running  
  
<pre> systemctl isolate multi-user.target (or) systemctl isolate runlevel3.target </pre>  
+
<pre> systemctl isolate multi-user.target </pre>  
  
 
You can switch to 'runlevel 5' by running  
 
You can switch to 'runlevel 5' by running  
  
<pre> systemctl isolate graphical.target (or) systemctl isolate runlevel5.target </pre>
+
<pre> systemctl isolate graphical.target </pre>
  
== How do I change the default runlevel? ==
+
== How do I change the default target? ==
  
systemd uses symlinks to point to the default runlevel. You have to delete the existing symlink first before creating a new one
+
<pre> systemctl set-default <name of target>.target </pre>
  
<pre> rm /etc/systemd/system/default.target </pre>
+
graphical.target is the default.  You might want multi-user.target for the equivalent of non graphical (runlevel 3) from sysv init. The full list of targets can be accessed via systemctl list-units --type=target
 
+
Switch to runlevel 3 by default
+
 
+
<pre> ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target </pre>
+
 
+
Switch to runlevel 5 by default
+
 
+
<pre> ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target </pre>
+
  
 
systemd does not use /etc/inittab file.
 
systemd does not use /etc/inittab file.
  
== How do I know the current run level? ==
+
== How do I know the current target? ==
  
runlevel command still works with systemd.  You can continue using that however runlevels is a legacy concept in systemd and is emulated via 'targets' and multiple targets can be active at the same time. So the equivalent in systemd terms is
+
<pre> systemctl get-default </pre>
  
<pre> systemctl list-units --type=target </pre>
+
== How to power off the machine ? ==
  
== How to power off the machine ? ==
 
 
You can use
 
You can use
<pre>
+
 
poweroff
+
<pre> poweroff </pre>
</pre>
+
  
 
Some more possibilities are: <code>halt -p</code>, <code>init 0</code>, <code>shutdown -P now</code>
 
Some more possibilities are: <code>halt -p</code>, <code>init 0</code>, <code>shutdown -P now</code>
Line 190: Line 121:
 
Yes.  It has been modified to call systemctl automatically when dealing with systemd service files.  So either of the following commands does the same thing
 
Yes.  It has been modified to call systemctl automatically when dealing with systemd service files.  So either of the following commands does the same thing
  
<pre> service NetworkManager stop </pre>
+
 
 +
<pre> systemctl stop NetworkManager </pre>
  
 
(or)
 
(or)
  
<pre> systemctl stop NetworkManager.service </pre>
+
<pre> service NetworkManager stop </pre>
  
 
== Does chkconfig command work with systemd? ==
 
== Does chkconfig command work with systemd? ==
Line 202: Line 134:
 
So either of the following commands does the same thing
 
So either of the following commands does the same thing
  
<pre> chkconfig NetworkManager off </pre>
+
<pre> systemctl disable NetworkManager </pre>
  
 
(or)
 
(or)
  
<pre> systemctl disable NetworkManager.service </pre>
+
<pre> chkconfig NetworkManager off </pre>
  
 
chkconfig --list doesn't list systemd services, only Sys V services.  The output of chkconfig takes note of this, along with supplying additional information.
 
chkconfig --list doesn't list systemd services, only Sys V services.  The output of chkconfig takes note of this, along with supplying additional information.
Line 212: Line 144:
 
== Does system-config-services work with systemd? ==
 
== Does system-config-services work with systemd? ==
  
The Fedora 15 or above version of system-config-services can cope with systemd service files. If you have problems, file a bug report.  
+
Yes. It does.
  
 
== How do I change the number of gettys running by default? ==
 
== How do I change the number of gettys running by default? ==
  
To add another getty:
+
The simplest way is to edit /etc/systemd/logind.conf ([http://www.freedesktop.org/software/systemd/man/logind.conf.html#NAutoVTs= man page]):
 +
 
 +
<pre>
 +
[Login]
 +
...
 +
NAutoVTs=8
 +
</pre>
 +
 
 +
This setting will take effect after reboot.
  
Simply place another symlink for instantiating another getty in the getty.target.wants/ directory:
+
Alternatively, getty@.services which open the login prompt can be enabled and started individually.
  
 +
To add another getty:
 
<pre>
 
<pre>
ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
+
systemctl enable getty@tty8
systemctl daemon-reload
+
systemctl start getty@tty8
systemctl start getty@tty9.service
+
 
</pre>
 
</pre>
  
 
To remove a getty:
 
To remove a getty:
 
Simply remove the getty symlinks you want to get rid of in the getty.target.wants/ directory:
 
  
 
<pre>
 
<pre>
rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
+
systemctl disable getty@tty8
systemctl daemon-reload
+
systemctl stop getty@tty8
systemctl stop getty@tty5.service getty@tty6.service
+
 
</pre>
 
</pre>
  
Line 269: Line 206:
 
== How do I customize a unit file/ add a custom unit file? ==
 
== How do I customize a unit file/ add a custom unit file? ==
  
The unit files in /etc/systemd/system have a higher precedence over unit files in /lib/systemd/system. Copy them from the latter to the former and customize it as per your requirements.  
+
The best way to customize unit files is to add /etc/systemd/system/foobar.service.d/*.conf where foobar.service is the name of the service you want to customize. If a directory doesn't already exist, create one and drop a conf file with the settings you want to override.  For example,
  
If a line starts with <code>.include</code> followed by a file name, the specified file will be parsed at this point. Make sure that the file that is included has the appropiate section headers before any directives.
+
/etc/systemd/system/httpd.service.d/restart.conf
  
You should use <code>.include</code> statement instead of copying the whole unit file from /lib/systemd/system to /etc/systemd/system if possible. This will enable to update the unchanged directives correctly during future package updates.
+
<pre>
 +
[Service]
 +
Restart=always
 +
RestartSec=30
 +
</pre>
  
Be careful when using <code>.include</code> together with directives that can be defined multiple times (like <code>EnvironmentFile=</code>), since we can only add new directives, but we can't remove already defined ones. We have to copy the whole file from /lib/systemd/system to /etc/systemd/system in this case.
+
Refer to man [http://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit] page for more details.  
  
Let's say we use a lighttpd server and we want to lower its niceness value. All we need to do is to add <code>Nice=-5</code> to the lighttpd.service file. We can do this by either copying the whole file from /lib/systemd/system/lighttpd.service to /etc/systemd/system/lighttpd.service or creating the following file in /etc/systemd/system/lighttpd.service:
+
{{admon/tip| Don't forget to reload systemd daemon using <code>systemctl daemon-reload</code> and <code> systemctl restart foobar</code> after editing a unit file where foobar is the name of the unit. Also note that you can <code> systemd-delta </code> to list the unit files which have been customized and also the precise differences }}
  
 +
Special care must be taken when overriding options which can be set muliple times (<code>ExecStart</code>, <code>ExecStartPre</code>, <code>ExecStartPost</code> are a common example). Assigning some value to the option ''appends'' to the existing list, while assiging the ''empty'' value ''resets'' the list.
 +
 +
For example, let's say we have a service file like this:
 
<pre>
 
<pre>
.include /lib/systemd/system/lighttpd.service
 
 
[Service]
 
[Service]
Nice=-5
+
ExecStart=/bin/echo execstart1
 +
ExecStart=
 +
ExecStart=/bin/echo execstart2
 +
ExecStartPost=/bin/echo post1
 +
ExecStartPost=/bin/echo post2
 +
</pre>
 +
When started, this service will print
 +
<pre>
 +
execstart2
 +
post1
 +
post2
 
</pre>
 
</pre>
  
Don't forget to reload systemd daemon using <code>systemctl daemon-reload</code> after editing a unit file.
+
The same rules apply to snippets in <code>.d</code> directories. This means that snippets which override
 
+
<code>ExecStart</code> and similar settings, often should start with the empty assignment <code>ExecStart=</code>, followed by the new setting.
 
+
{{admon/note|When modifying an unit that has an symlink pointing to that unit for example like the display-manager.service -> prefdm.service does, the symlink should be copied instead of the actual unit as in display-manager.service should be copied to the /etc/systemd/system directory or a new unit created with .includes that bears that name .}}
+
  
 
== How do I debug systemd issues? ==
 
== How do I debug systemd issues? ==
  
 
Refer to [[How_to_debug_Systemd_problems]]
 
Refer to [[How_to_debug_Systemd_problems]]
 
= Readahead =
 
 
systemd has a built-in readahead implementation which is not enabled on upgrades. It should improve bootup speed but your mileage may vary depending on your hardware.  To enable it:
 
 
<pre>
 
systemctl enable systemd-readahead-collect.service
 
systemctl enable systemd-readahead-replay.service
 
</pre>
 
 
= Warnings on separate /usr partition =
 
 
Refer to http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken and http://cgit.freedesktop.org/systemd/tree/README for details.
 
  
 
= Man pages =
 
= Man pages =
  
systemd comes with extensive documentation including several man pages. The web version is at
+
systemd comes with extensive documentation including several man pages.
  
http://0pointer.de/public/systemd-man/
+
On the web: [http://www.freedesktop.org/software/systemd/man/ list of all systemd man pages],
 +
[http://www.freedesktop.org/software/systemd/man/systemd.directives.html index of all settings].
  
 
= References =
 
= References =
  
 +
* [http://www.freedesktop.org/wiki/Software/systemd Project homepage]
 
* http://0pointer.de/blog/projects/  -  Lennart's blog has lots of information about systemd. Lennart is the primary systemd developer
 
* http://0pointer.de/blog/projects/  -  Lennart's blog has lots of information about systemd. Lennart is the primary systemd developer
 
* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
 
* http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions
 
* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
 
* http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks
 
* [[Features/systemd | Features Fedora 15:systemd]]
 
* [[Features/systemd | Features Fedora 15:systemd]]
* [http://www.freedesktop.org/wiki/Software/systemd Project homepage]
 
 
* [http://fosdem.org/2011/interview/lennart-poettering.html Interview with the developer]
 
* [http://fosdem.org/2011/interview/lennart-poettering.html Interview with the developer]
* [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]
 

Latest revision as of 19:20, 27 July 2014

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, 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. For more information, watch the video at http://linuxconfau.blip.tv/file/4696791/ or http://www.youtube.com/watch?v=TyMLi8QF6sw

Note.png
For system administrators
System administrators can visit this page, to understand how to use the native systemctl calls that replace their old workflow in SysVinit. Note that the service and chkconfig commands will continue to work as expected in the systemd world.

Contents

[edit] Why systemd?

http://0pointer.de/blog/projects/why.html

[edit] systemd documentation

systemd has very comprehensive documentation. Refer to

http://0pointer.de/blog/projects/systemd-docs.html

[edit] Tools

  • systemctl: used to introspect and control the state of the systemd system and service manager
  • systemd-cgls: recursively shows the contents of the selected Linux control group hierarchy in a tree
  • systemadm: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd. Part of the systemd-gtk package. This is an early version and needs more work. Do not use it for now unless you are a developer.

View the man pages for more details.

[edit] Boot Kernel Command Line

On boot systemd activates (by default), the target unit default.target whose job is to activate services and other units by pulling them in via dependencies.

To override the unit to activate, systemd parses its own kernel command line arguments via the systemd.unit= command line option. This may be used to temporarily boot into a different boot unit. The classical run-levels are replaced as following:

systemd.unit=rescue.target is a special target unit for setting up the base system and a rescue shell (similar to run level 1); systemd.unit=emergency.target, is very similar to passing init=/bin/sh but with the option to boot the full system from there; systemd.unit=multi-user.target for setting up a non-graphical multi-user system; systemd.unit=graphical.target for setting up a graphical login screen.

For details about these special systemd boot units, view the man systemd.special page. it scripts

[edit] What is the tool to manage services with systemd?

systemctl is the primary tool to use. It combines the functionality of both service and chkconfig into a single tool that you can use for instance to enable/disable services permanently or only for the current session.

list all running services etc:

 systemctl 

Refer to man systemctl for more details. systemd-cgls lists the running process in a tree format. It can recursively show the content of any given control group. Refer to man systemd-cgls for more details.

[edit] How do I start/stop or enable/disable services?

Activates a service immediately:

  systemctl start foo 

Deactivates a service immediately:

  systemctl stop foo 

Restarts a service:

 systemctl restart foo 

Shows status of a service including whether it is running or not:

 systemctl status foo 

Enables a service to be started on bootup:

 systemctl enable foo 

Disables a service to not start during bootup:

 systemctl disable foo 

Prevent a service from starting dynamically or even manually unless unmasked:

 systemctl mask foo 

Check whether a service is already enabled or not:

 systemctl is-enabled foo

Refer to man systemctl for more details.

[edit] How do I change the target (runlevel) ?

systemd has the concept of targets which is a more flexible replacement for runlevels in sysvinit.

Run level 3 is emulated by multi-user.target. Run level 5 is emulated by graphical.target. runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target.

You can switch to 'runlevel 3' by running

 systemctl isolate multi-user.target 

You can switch to 'runlevel 5' by running

 systemctl isolate graphical.target 

[edit] How do I change the default target?

 systemctl set-default <name of target>.target 

graphical.target is the default. You might want multi-user.target for the equivalent of non graphical (runlevel 3) from sysv init. The full list of targets can be accessed via systemctl list-units --type=target

systemd does not use /etc/inittab file.

[edit] How do I know the current target?

 systemctl get-default 

[edit] How to power off the machine ?

You can use

 poweroff 

Some more possibilities are: halt -p, init 0, shutdown -P now

Note that halt used to work the same as poweroff in previous Fedora releases, but systemd distinguishes between the two, so halt without parameters now does exactly what it says - it merely stops the system without turning it off.

[edit] Does service command work with systemd?

Yes. It has been modified to call systemctl automatically when dealing with systemd service files. So either of the following commands does the same thing


 systemctl stop NetworkManager 

(or)

 service NetworkManager stop 

[edit] Does chkconfig command work with systemd?

Yes, for turning on/off services, compatibility has been provided both ways. chkconfig has been modified to call systemctl when dealing with systemd service files. Also systemctl automatically calls chkconfig when dealing with a traditional sysv init file.

So either of the following commands does the same thing

 systemctl disable NetworkManager 

(or)

 chkconfig NetworkManager off 

chkconfig --list doesn't list systemd services, only Sys V services. The output of chkconfig takes note of this, along with supplying additional information.

[edit] Does system-config-services work with systemd?

Yes. It does.

[edit] How do I change the number of gettys running by default?

The simplest way is to edit /etc/systemd/logind.conf (man page):

[Login]
...
NAutoVTs=8

This setting will take effect after reboot.

Alternatively, getty@.services which open the login prompt can be enabled and started individually.

To add another getty:

systemctl enable getty@tty8
systemctl start getty@tty8

To remove a getty:

systemctl disable getty@tty8
systemctl stop getty@tty8

systemd does not use /etc/inittab file.

[edit] How do I set automatic login on a virtual console terminal?

First create a new service similar to getty@.service:

# cp /lib/systemd/system/getty@.service \
     /etc/systemd/system/autologin@.service
# ln -s /etc/systemd/system/autologin@.service \
        /etc/systemd/system/getty.target.wants/getty@tty8.service

then edit ExecStart, Restart and Alias values, like this:

...
ExecStart=-/sbin/mingetty --autologin USERNAME %I
Restart=no
...
Alias=getty.target.wants/getty@tty8.service

and finally reload daemon and start the service:

systemctl daemon-reload
systemctl start getty@tty8.service

Note that if you exit tty8 session, you wont be able to use it until next reboot or manual start by systemctl, except if you leave Restart as ‘always’, but I highly recommend to avoid this according to security reasons.

[edit] How do I customize a unit file/ add a custom unit file?

The best way to customize unit files is to add /etc/systemd/system/foobar.service.d/*.conf where foobar.service is the name of the service you want to customize. If a directory doesn't already exist, create one and drop a conf file with the settings you want to override. For example,

/etc/systemd/system/httpd.service.d/restart.conf

[Service]
Restart=always
RestartSec=30

Refer to man systemd.unit page for more details.

Idea.png
Don't forget to reload systemd daemon using systemctl daemon-reload and systemctl restart foobar after editing a unit file where foobar is the name of the unit. Also note that you can systemd-delta to list the unit files which have been customized and also the precise differences

Special care must be taken when overriding options which can be set muliple times (ExecStart, ExecStartPre, ExecStartPost are a common example). Assigning some value to the option appends to the existing list, while assiging the empty value resets the list.

For example, let's say we have a service file like this:

[Service]
ExecStart=/bin/echo execstart1
ExecStart=
ExecStart=/bin/echo execstart2
ExecStartPost=/bin/echo post1
ExecStartPost=/bin/echo post2

When started, this service will print

execstart2
post1
post2

The same rules apply to snippets in .d directories. This means that snippets which override ExecStart and similar settings, often should start with the empty assignment ExecStart=, followed by the new setting.

[edit] How do I debug systemd issues?

Refer to How_to_debug_Systemd_problems

[edit] Man pages

systemd comes with extensive documentation including several man pages.

On the web: list of all systemd man pages, index of all settings.

[edit] References