{"id":948,"date":"2014-03-14T06:00:37","date_gmt":"2014-03-14T03:00:37","guid":{"rendered":"http:\/\/joseph.zikusooka.com\/?p=948"},"modified":"2014-03-16T12:46:40","modified_gmt":"2014-03-16T09:46:40","slug":"systemd-will-start-next-linux-system","status":"publish","type":"post","link":"https:\/\/joseph.zikusooka.com\/?p=948","title":{"rendered":"Why SystemD will start your next Linux system"},"content":{"rendered":"

For a long time, the default boot and initialization mechanism in Linux was the System V (SysV) init daemon. Along the way, many Linux distributions have attempted to move away from this primitive form of booting. Why you ask? For one thing, it makes the boot process a lot slower, s<\/span>ince processes have to be started one at a time. It is also a nightmare to maintain the scripts that Administrators write to manage these start processes, as each package maintainer or administrator, does ‘their own thing.’<\/span><\/p>\n

\"Linux<\/a><\/p>\n

 <\/p>\n

So Ubuntu, one of the most popular Linux distributions move<\/span>d to upstart in late 2006, but this init da<\/span>emon they adopted, was not widely embraced. Debian, OpenSuse, Fedora, and Red Hat at some point in the last five years supported upstart. Red Hat Enterprise Linux (RHEL) version 6 and derivatives such as \u00a0CentOS \u00a0still use upstart. But all of them are ditching upstart for something better, i.e. SystemD. In fact, the Debian technical committee <\/span>recently voted<\/a> and they will switch to SystemD in upcoming releases, leaving Ubuntu <\/span>no choice<\/a> but to follow.<\/span><\/p>\n

It now looks like SystemD will be the default initialization and boot method for Linux systems for many years to come. But what does systemD do different?<\/p>\n

What is SystemD?<\/strong><\/p>\n

SystemD<\/a>, is a system and services manager for Linux that was developed by a team from Red Hat, spearheaded by Lennart Poettering<\/a>, the creator of pulseaudio, and Avahi. SystemD makes Linux systems boot faster since processes are ran in parallel. Once started, processes are monitored, and restarted if they crash. SystemD also reduces the dependency on shell scripts to do much of the work.<\/p>\n

Other systemD features, include a cron-like job scheduler, an integrated login manager, which offers ‘multi-seating’ functions. It also has a new an improved logging mechanism called the journal, that will likely replace syslog, the current logging facility on Linux systems.<\/p>\n

Below is some technical information to get you as the administrator started with systemD. Please note that there are several manuals and online resources available that will help you understand systemD, I will mention a few at the end of this post.<\/p>\n

How to get started with systemD<\/strong><\/p>\n

SystemD is installed by default on recent versions of Fedora, and Arch Linux. For other distributions like Debian and Ubuntu, you might have to wait a bit for systemd to be packaged as the default init system. It is actually recommended that installation is done by the distribution vendors. But if you are the brave type, you can of course install it from source.<\/p>\n

Pick up the source tarball<\/a> and follow the instructions contained in the README file included with the sources.<\/p>\n

After installation is completed, you will need to start converting your old startup scripts to systemD. At this time, only SysV init scripts for commonly used services, have been ported to systemD. So you will need to know how to write a service file for rarely used daemons or for that program you are developing. Below is an example of a systemd service file. By the way, these are what those files in “\/etc\/init.d” used to be.<\/p>\n

How to write a systemD service file<\/strong><\/p>\n

Open up your favorite editor such as vim as follows:
\nvim \/tmp\/squid.service\u00a0<\/code>Am using squid here as an example, so replace it with the name of your service. Enter the following snippet:<\/span><\/p>\n

[Unit]
\nDescription=Squid caching proxy
\n<\/span>After=syslog.target network.target nss-lookup.target<\/span><\/p>\n

[Service]
\nType=forking
\nEnvironmentFile=\/etc\/sysconfig\/squid
\nExecStartPre=\/usr\/libexec\/squid\/cache_swap.sh
\nExecStart=\/usr\/sbin\/squid $SQUID_OPTS -f $SQUID_CONF
\nExecReload=\/usr\/sbin\/squid $SQUID_OPTS -k reconfigure -f $SQUID_CONF
\nExecStop=\/usr\/sbin\/squid -k shutdown -f $SQUID_CONF
\nPIDFile=\/var\/run\/squid.pid<\/p>\n

[Install]
\nWantedBy=multi-user.target<\/p>\n

At a minimum, you will need these three sections; unit, service, install.<\/p>\n

Unit definitions<\/strong>
\nDescription: A string describing the service and what it does.
\nAfter: If service depends on another one, then indicate that it should come after those targets. Notice in my example that one of the pre-requisites for this service is the network service. You will see that often, as most services expect the network to be already running, so always include it.
\nYou can also add ‘Before’ which does the opposite and starts this service before units listed.
\nHint: You can read more about unit definitions by calling up the manpage: man systemd.unit<\/p>\n

Service definitions<\/strong>
\nType: You must always have a type, which can either be forking, simple, oneshot, dbus, or notify. For most daemons, forking should suffice, as it forks the processes by putting them in the background after start.
\nEnvironmentFile:This is the file which contains the options used by your service daemon. This can be omitted, but can be a life saver occasionally
\nExecStartPre: This is the command that is called before the main process – see ExecStart
\nExecStart: This is the command that the daemon runs. You can also point to a script on your system e.g. =\/bin\/sh -c “\/usr\/sbin\/my-cool-script.sh”
\nExecStartPost: This is the command that is called after the main process – see ExecStart
\nExecReload: This is the command that is called in order to reload the daemon’s configuration file.
\nExecStop: This is the command that is used to stop your service.
\nPIDFile: Enter the file path containing the process ID of your service. SystemD reads this file after startup.
\nHint: You can read more about service definitions by calling up the manpage: man systemd.service<\/p>\n

Install definitions<\/strong>
\nThis section is optional, but can be used to set the target level
\nWantedBy: Set a target where this service will be grouped. Like run levels in SysV language.
\nHint: You can read more about various special targets by calling up the manpage: man systemd.special<\/p>\n

Activating your systemd service<\/strong><\/p>\n

When you are done writing the service file, copy it to: \/usr\/lib\/systemd\/system\/
\ncp -v \/tmp\/squid.service \/usr\/lib\/systemd\/system\/<\/code><\/p>\n

You will need reload the systemd daemon:
\nsystemctl --system daemon-reload
\n<\/code>In order for the service to start automatically at boot time, enable your systemd service as follows:
\n<\/span>systemctl enable squid.service<\/code>
\n<\/span>Now when you want to start, stop, reload or check the status of this service; do the following:<\/span><\/p>\n

systemctl COMMAND squid.service<\/code> ; where COMMAND is either {start|stop|reload|status}<\/p>\n

This how-to barely scratches the surface. There are lots of neat tricks you can perform with systemD that your old dog SysV and upstart could not. So take the time to learn it.<\/p>\n

Resources:<\/strong>
\nSystemD website: http:\/\/www.freedesktop.org\/wiki\/Software\/systemd<\/a>
\nLennart’s Blog: http:\/\/0pointer.de\/blog<\/a>(Look for the SystemD series for Administrators)
\nMailing List: http:\/\/lists.freedesktop.org\/archives\/systemd-devel<\/a>
\nMan pages: systemd- (Use tab completion to see all available man pages)<\/p>\n","protected":false},"excerpt":{"rendered":"

For a long time, the default boot and initialization mechanism in Linux was the System V (SysV) init daemon. Along the way, many Linux distributions have attempted to move away from this primitive form of booting. Why you ask? For one thing, it makes the boot process a lot slower, since processes have to be […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":3,"footnotes":""},"categories":[6],"tags":[],"class_list":["post-948","post","type-post","status-publish","format-standard","hentry","category-apps"],"_links":{"self":[{"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/posts\/948","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=948"}],"version-history":[{"count":11,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/posts\/948\/revisions"}],"predecessor-version":[{"id":960,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=\/wp\/v2\/posts\/948\/revisions\/960"}],"wp:attachment":[{"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=948"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=948"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/joseph.zikusooka.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=948"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}