Frequently Asked Questions
Also check out the Tips & Tricks!
Q: How do I change the current runlevel?
A: In systemd runlevels are exposed via "target units". You can change them like this:
# systemctl isolate runlevel5.target
Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:
# systemctl isolate graphical.target
This will only change the current runlevel, and has no effect on the next boot.
Q: How do I change the default runlevel to boot into?
A: The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:
# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
or
# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
Q: How do I figure out the current runlevel?
A: Note that there might be more than one target active at the same time. So the question regarding the runlevel might not always make sense. Here's how you would figure out all targets that are currently active:
$ systemctl list-units --type=target
If you are just interested in a single number, you can use the venerable runlevel command, but again, its output might be misleading.
Q: I want to change a service file, but rpm keeps overwriting it in /lib/systemd/system all the time, how should I handle this?
A: The recommended way is to copy the service file from /lib/systemd/system to /etc/systemd/system and edit it there. The latter directory takes precedence over the former, and rpm will never overwrite it. If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again.
Q: My service foo.service as distributed by my operating system vendor is only started when (a connection comes in | some hardware is plugged in). I want to have it started always on boot, too. What should I do?
A: Simply place a symlink from that service file in the multi-user.target.wants/ directory (which is where you should symlink everything you want to run in the old runlevel 3, i.e. the normal boot-up without graphical UI. It is pulled in by graphical.target too, so will be started for graphical boot-ups, too):
# ln -sf /lib/systemd/system/foobar.service /etc/systemd/system/multi-user.target.wants/foobar.service # systemctl daemon-reload
Q: I want to enable another getty, how would I do that?
A: Simply place another symlink for instantiating another getty in the getty.target.wants/ directory:
# ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service # systemctl daemon-reload # systemctl start getty@tty9.service
Q: I want to remove one or more gettys, how would I do that?
A: Simply remove the getty symlinks you want to get rid of in the getty.target.wants/ directory:
# rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service # systemctl daemon-reload # systemctl stop getty@tty5.service getty@tty6.service
Q: How to I figure out which service a process belongs to?
A: You may either use ps for that:
$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc ...
Or you can even check /proc/$PID/cgroup directly.
Q: Why don't you use inotify to reload the unit files automatically on change?
A: Unfortunately that would be a racy operation. For an explanation why and how we tried to improve the situation, see https://bugzilla.redhat.com/show_bug.cgi?id=615527
Q: I have a native systemd service file and a SysV init script installed which share the same basename, e.g. /lib/systemd/system/foobar.service vs. /etc/init.d/foobar -- which one wins?
A: If both files are available the native unit file always takes precedence and the SysV init script is ignored, regardless whether either is enabled or disabled. Note that a SysV service that is enabled but overriden by a native service does not have the effect that the native service would be enabled, too. Enabling of native and SysV services is completely independent. Or in other words: you cannot enable a native service by enabling a SysV service by the same name, and if a SysV service is enabled but a the respective native service is not, this will not have the effect that the SysV script is executed.