This is a document to help system administrators who need to understand what commands in systemd replace their old workflow in SysVinit.

+

{{autolang|base=yes}}

−

Note that the 'service' and 'chkconfig' commands will continue to work as expected in the systemd world, this guide is how to use the native

+

This is a document to help system administrators who need to understand what commands in systemd replace their old workflow in sysvinit. If you want general information on systemd, refer to [[systemd]].

−

systemctl calls that are being made by those commands.

+

+

{{admon/tip | Note on 'service' and 'chkconfig' commands | The 'service' and 'chkconfig' commands will mostly continue to work as expected in the systemd world, this guide is how to use the native

+

systemctl replacements. }}

== Services ==

== Services ==

{|

{|

−

!SystemVinit Command!!Systemd Command!!Notes

+

!sysvinit Command!!systemd Command!!Notes

|-

|-

−

| ls -al /etc/rc.d/init.d || systemctl --all --type=service || Used to list the services that can be started or stopped

| ls /etc/rc.d/init.d/ || systemctl list-unit-files --type=service (preferred)<br />ls /lib/systemd/system/*.service /etc/systemd/system/*.service|| Used to list the services that can be started or stopped <br /> Used to list all the services and other units

|-

|-

−

| service frobozz condrestart || systemctl reload-or-restart frobozz.service OR systemctl condrestart frobozz.service OR service frobozz condrestart || When supported, restarts if the service is already running.

+

| chkconfig frobozz on || systemctl enable frobozz.service || Turn the service on, for start at next boot, or other trigger.

+

|-

+

| chkconfig frobozz off || systemctl disable frobozz.service || Turn the service off for the next reboot, or any other trigger.

+

|-

+

| chkconfig frobozz || systemctl is-enabled frobozz.service || Used to check whether a service is configured to start or not in the current environment.

+

|-

+

| chkconfig --list || systemctl list-unit-files --type=service (preferred)<br/>ls /etc/systemd/system/*.wants/ || Print a table of services that lists which runlevels each is configured on or off

+

|-

+

| chkconfig frobozz --list || ls /etc/systemd/system/*.wants/frobozz.service || Used to list what levels this service is configured on or off

+

|-

+

| chkconfig frobozz --add || systemctl daemon-reload || Used when you create a new service file or modify any configuration

|-

|-

|}

|}

+

+

Note that all /sbin/service and /sbin/chkconfig lines listed above continue to work on systemd, and will be translated to native equivalents as necessary. The only exception is chkconfig --list.

{{admon/warning|Additional commands|In SysVinit, services can define arbitrary commands. Examples would be '''service iptables panic''', or '''service httpd graceful'''. Native systemd services do not have this ability.

{{admon/warning|Additional commands|In SysVinit, services can define arbitrary commands. Examples would be '''service iptables panic''', or '''service httpd graceful'''. Native systemd services do not have this ability.

Line 34:

Line 46:

Check the package-specific release notes for any services that may have done this.}}

Check the package-specific release notes for any services that may have done this.}}

−

== Runlevels ==

+

== Runlevels/targets ==

−

runlevels are used with telinit and on the kernel command line in SystemVinit. These traditional ways of switching runlevels still work with systemd, but additionally, the following can be used instead.

+

Systemd has a concept of ''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. 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 sysvinit runlevels so you can still switch ''target''s using the familiar <code>telinit RUNLEVEL</code> command. 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's 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 <code>/etc/systemd/system/$YOURTARGET</code> that takes one of the existing runlevels as a base (you can look at <code>/lib/systemd/system/graphical.target</code> as an example), make a directory <code>/etc/systemd/system/$YOURTARGET.wants</code>, and then symlink the additional services that you want to enable into that directory. (The service unit files that you symlink live in <code>/lib/systemd/system</code>).

Revision as of 18:24, 11 April 2012

This is a document to help system administrators who need to understand what commands in systemd replace their old workflow in sysvinit. If you want general information on systemd, refer to systemd.

Note on 'service' and 'chkconfig' commands The 'service' and 'chkconfig' commands will mostly continue to work as expected in the systemd world, this guide is how to use the native
systemctl replacements.

Services

sysvinit Command

systemd Command

Notes

service frobozz start

systemctl start frobozz.service

Used to start a service (not reboot persistent)

service frobozz stop

systemctl stop frobozz.service

Used to stop a service (not reboot persistent)

service frobozz restart

systemctl restart frobozz.service

Used to stop and then start a service

service frobozz reload

systemctl reload frobozz.service

When supported, reloads the config file without interrupting pending operations.

Print a table of services that lists which runlevels each is configured on or off

chkconfig frobozz --list

ls /etc/systemd/system/*.wants/frobozz.service

Used to list what levels this service is configured on or off

chkconfig frobozz --add

systemctl daemon-reload

Used when you create a new service file or modify any configuration

Note that all /sbin/service and /sbin/chkconfig lines listed above continue to work on systemd, and will be translated to native equivalents as necessary. The only exception is chkconfig --list.

Additional commandsIn SysVinit, services can define arbitrary commands. Examples would be service iptables panic, or service httpd graceful. Native systemd services do not have this ability.

Any service that defines an additional command in this way would need to define some other, service-specific, way to accomplish this task when writing a native systemd service definition.

Check the package-specific release notes for any services that may have done this.

Runlevels/targets

Systemd has a concept of 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. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common sysvinit runlevels so you can still switch targets using the familiar telinit RUNLEVEL command. 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's 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 /etc/systemd/system/$YOURTARGET that takes one of the existing runlevels as a base (you can look at /lib/systemd/system/graphical.target as an example), make a directory /etc/systemd/system/$YOURTARGET.wants, and then symlink the additional services that you want to enable into that directory. (The service unit files that you symlink live in /lib/systemd/system).

sysvinit Runlevel

systemd Target

Notes

0

runlevel0.target, poweroff.target

Halt the system.

1, s, single

runlevel1.target, rescue.target

Single user mode.

2, 4

runlevel2.target, runlevel4.target, multi-user.target

User-defined/Site-specific runlevels. By default, identical to 3.

3

runlevel3.target, multi-user.target

Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.

5

runlevel5.target, graphical.target

Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.