King Files

Systemd for Fedora

Systemd has been the standard "init" process on Fedora since Fedora 15. As it is compatible with SysV init scripts, LSB and chkconfig headers, it can seamlessly replace other "init" daemons like Upstart and Sysvinit.

Advantages:

• On-demand bus activation of services
• Aggressive parallelization of socket services
• Support for Linux cgroups for managing process resources
• Able to mount/unmount/automount filesystems
• Capable of starting services based upon time
• Elaborate transactional dependencies between services

Disadvantages:

• Requires understanding new concepts
• Requires learning a new configuration syntax for startup scripts
• Not entirely compatible with all init, telinit, or service commands
• Requires new method for taking the system to different runlevels  

Ultimately, systemd should provide you with a smoother, faster, and more efficient start up of your system. With capabilities like automounting and scheduling execution, it may even end up replacing more daemons than just init. Hopefully, by the end of this post, you will have a better idea of how to cope with the disadvantages of systemd.

If youve been using Fedora since 15 came out, then youve already been using systemd. You might not know it, until that day comes when you need to do something like rescue an unbootable system. Instead of simply passing a number representing a runlevel to the kernel, systemd uses a kernel parameter called systemd.unit.

Units

A systemd unit can be of several different types: service, socket, device, special, and target. Targets are used to group the other types of units into something similar to a runlevel. As an example, for CUPS to work there  is the cups.service, cups.socket, and the cups.path.

Targets

There are a number of predefined targets that can boot the system into different modes. Most desktop users who will want the a graphical user interface will want to use graphical.target. For systems like servers without the need for a GUI will want to use multi-user.target.

Setting The Default Runlevel

To set the default runlevel, remove the existing link in the /etc/systemd/system directory to default.target. Then, create a new link to one of the targets like multi-user.rarget or graphical.target in the /lib/systemd/system directory:
rm -f /etc/systemd/system/default.target
ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Changing Runlevels While Booting

In order to get to the equivalent of rescue mode, append the kernel with systemd.unit=rescue.target.
To only start up an emergency shell add the kernel parameter systemd.unit=emergency.target.
To get a non-graphical networked mode, use the kernel parameter systemd.unit=multi-user.target.
If X is installed, force the GUI mode with the kernel parameter systemd.unit=graphical.target

Changing Runlevels While Running

To do a poweroff or halt command, or like init 0, use: systemctl poweroff
The equivalent of init 3 is: systemctl isolate multi-user.target
The equivalent of init 5 is: systemctl isolate graphical.target
To do a reboot or init 6, use: systemctl reboot

Managing Services

Like service httpd start is systemctl start httpd.service 
Like service httpd stop is systemctl stop httpd.service
Like service httpd status is systemctl status httpd.service
Like service --status-all is systemctl --all or systemctl -a

Enabling/Disabling Services

sudo update-rc.d apache2 disable