Article by Stuart Burns first posted on Openlogic.com
With Red Hat Enterprise Linux 7 released and CentOS version 7 newly unveiled, now is a good time to cover systemd, the replacement for legacy System V (SysV) startup scripts and runlevels. Red Hat-based distributions are migrating to systemd because it provides more efficient ways of managing services and quicker startup times. With systemd there are fewer files to edit, and all the services are compartmentalized and stand separate from each other. This means that should you screw up one config file, it won’t automatically take out other services.
Systemd has been the default system and services manager in Red Hat Fedora since the release of Fedora 15, so it is extensively field-tested. It provides more consistency and troubleshooting ability than SysV – for instance, it will report if a service has failed, is suspended, or is in error. Perhaps the biggest reason for the move to systemd is that it allows multiple services to start up at the same time, in parallel, making machine boot times quicker than they would be with legacy runlevels.
Under systemd, services are now defined in what are termed unit files, which are text files that contain all the configuration information a service needs to start, including its dependencies. Service files are located in /usr/lib/systemd/system/. Many but not all files in that directory will end in .service; systemd also manages sockets and devices.
No longer do you directly modify scripts to configure runlevels. Within systemd, runlevels have been replaced by the concept of states. States can be described as “best efforts” to get a host into a desired configuration, whether it be single-user mode, networking non-graphical mode, or something else. Systemd has some predefined states created to coincide with legacy runlevels. They are essentially aliases, designed to mimic runlevels by using systemd.
States require additional components above and beyond services. Therefore, systemd uses unit files not only to configure services, but also mounts, sockets, and devices. These units’ names end in .sockets, .devices, and so on.
Targets, meanwhile, are logical groups of units that provide a set of services. Think of a target as a wrapper in which you can place multiple units, making a tidy bundle to work with.
Unit files are built from several configurable sections, including unit descriptions and dependencies. Systemd also allows administrators to explicitly define a service’s dependencies and load them before the given service starts by editing the unit files. Each unit file has a line that starts After= that can be used to define what service is required before the current service can start. WantedBy=lines specify that a target requires a given unit.
Targets have more meaningful names than those used in SysV-based systems. A name like graphical.target gives admins an idea of what a file will provide! To see the current target at which the system is residing, use the command systemctl get-default. To set the default target, use the command systemctl set-default targetname.target. targetname can be, among others:
- rescue.target
- multi-user.target
- graphical.target
- reboot.target
Looking at the above it becomes obvious that although there is no direct mapping between runlevels and targets, systemd provides what could loosely be termed equivalent levels.
Another important feature systemd implements is cgroups, short for control groups, which provide security and manageability for the resources a system can use and control. With cgroups, services that use the same range of underlying operating system calls are grouped together. These control groups then manage the resources they control. This grouping performs two functions: it allows administrators to manage the amount of resources a group of services gets, and it provides additional security in that a service in a certain cgroup can’t jump outside of cgroups control, preventing it for example from getting access to other resources controlled by other cgroups.
Cgroups existed in the old SysV model, but were not really implemented well. systemd attempts to fix this issue.
First steps in systemd
Under systemd you can still use the service and chkconfig commands to manage those additional legacy services, such as Apache, that have not yet been moved over to systemd management. You can also use service command to manage systemd-enabled services. However, several monitoring and logging services, including cron and syslog, have been rewritten to use the functionality that is available in systemd, in part because scheduling and some of the cron functionality is now provided by systemd.
How can you start managing systemd services? Now that Centos 7 is out of the starting gate we can start to experiment with systemd and understand its operation. To begin, as the root user in a terminal, type chkconfig. The output shows all the legacy services running. As you can see by the big disclaimer, most of the other services that one would expect to be present are absent, because they have been migrated to systemd management.
Red Hat-based OSes no longer use the old /etc/initab file, but instead use a system.default configuration file. You can symlink a desired target to the system.default in order to have that target start up when the system boots. To configure the target to start a typical multi-user system, for example, run the command below:
ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
After you make the symlink, run systemctl, the replacement for chkconfig. Several pages of output display, listing all the services available:
- Unit – the service name
- Load – gives status of the service (such as Loaded, Failed, etc.)
- Active – indicates whether the status of the service is Active
- Description – textual description of the unit
The key commands and arguments in systemctl are similar to the legacy ones found in chkconfig – for example, systemctl start postfix.service.
In the same vein, use systemctl stop and systemctl status to stop services or view information. This syntax similarity to chkconfig arguments is by design, to make the transition to systemd as smooth as possible.
To see all the services you can start using systemctl and their statuses, use the command
systemctl list-unit-files --type=service
While you can no longer enable a runlevel for a service using chkconfig --level, under systemd you can enable or disable a service when it boots. Use systemctl enable service to enable a service, and systemctl disable service to keep it from starting at boot. Get a service’s current status (enabled or disabled) with the command systemctl is-enabled service.
Final thoughts on systemd
It may take you some time to get used to systemd, but you should plan to use it now before it becomes a requirement and management through legacy tools is no longer available. You should find that systemd makes managing services easier than it used to be with SysV.
Popular Posts:
- None Found
Why are you republishing the whole article written and published elsewhere?
The proper way of sharing some one else’ article is to show a “snippet” only here, and point readers to the origninal source. I see you promoting theses republished articles using your urls, not theirs. This is not ethical.
Thomas
Hello Thomas,
When I find an useful article that has a compatible license (this one is a CC SA BY) I republish it on my blog so my readers can read it as well.
Usually i publish as first line the author name and the original link so everyone can read it from the original source, and another thing that I do it’s translate it in Italian.
As you wrote I could just put the first lines, but I prefer to repost the whole article (over time some of the blog from where I’ve took some articles have closed, so my copy could be now the only one), it’s a choice, but I don’t feel un-ethical for this, after all my goal it’s to post/share good articles that can help the readers.
BTW, Also all the articles that I wrote are licensed under CC BY SA as well, so every one is free to repost them, they just have to put my name on the top (or bottom)
Best Regards
I don’t mind that someone else copies an article, so long as they comply with the copyright policy and that they link to the original source. Some times the original source gets taken down and its nice to know that it is documented somewhere else.
You said:
>> The proper way of sharing some one else’ article is to show a “snippet” only here,….
I disagree. As @linuxari says, he’s correctly attributed the article to the publisher/ author. There’s (almost) nothing more frustrating when searching the web for a useful solution to a problem, finding a snippet that looks good, and finding a dead link to the original article.
Yes, it’s somewhat inefficient in storage space, but it ensures that the information will be there in future.
D.
I personally think it’s awesome that the article was reproduced in its entirety.
I think it was great, read the whole thing and learned something. As long as it doesn’t go against copyright laws, it is a good idea. Thanks for posting.
-Dennis
Hi, I can have a service running in both chkconfig and in systemd? Systemd do not provide different actions to start, stop …, which allows me to have chkconfig, so keep the service in both.
Thank goodness I stopped using CentOS at version 6, sad to see Potterware claims another Linux distro…..