Book Excerpt: A Practical Guide to Fedora and Red Hat Enterprise Linux
Changing the Current Runlevel
The systemctl isolate command changes the current runlevel of the system. The following command changes the runlevel to multiuser graphical mode (graphical.target). When the system is rebooted, it will return to the default runlevel as specified by the link at /etc/systemd/system/default.target.
# systemctl isolate graphical.target
After a few moments, systemctl shows the system is in the runlevel specified by graphical.target:
$ systemctl list-units --type=target ... graphical.target loaded active active Graphical Interface ...
The preceding examples were run from an ssh login. If you give these commands from a terminal emulator running in a GUI, the system will log you out each time the system changes runlevel.
Configuring Daemons (Services)
Two states are important when you consider a daemon: its current state and its persistent state (the state it will be in after the system is booted). Possible states are running and stopped. Under Fedora, daemons are stopped when they are installed and are set up to be stopped after the system is booted.
The systemctl utility controls the current and persistent states of daemons that run natively under systemd. The service and chkconfig utilities originally controlled daemons that run under SysVinit and were upgraded to control daemons that run under Upstart. Now these utilities have been retrofitted to control daemons that run under systemd, which they do by calling systemctl. You can still use service to control the current state of a daemon and chkconfig to control the persistent state of a daemon.
The next sections describe the systemctl commands that control daemons, followed by the service or chkconfig commands that perform the same functions.
Setting the Persistent State of a Daemon (Service)
The systemctl disable command causes a daemon not to start when the system is booted. This command has no effect on the current state of the daemon. You must specify the .service part of the service name.
# systemctl disable ntpd.service rm '/etc/systemd/system/multi-user.target.wants/ntpd.service'
The preceding command removes the link that causes systemd to start ntpd when the system enters multi-user runlevel and, by inheritance, graphical runlevel. See “/etc/systemd/system Hierarchy: Controls Services and the Persistent Runlevel” for a discussion of these links.
The preceding command works on the ntpd daemon, which is run natively by systemd. If you run the same command on a daemon controlled by a SysVinit script, such as cups, it calls chkconfig (covered shortly). Even though no cups.service service or file exists, you must specify the .service part of the service name.
# systemctl disable cups.service cups.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig cups off
The following commands each verify the ntpd daemon will not start when the system boots. The first command shows no links in the .wants directories for ntpd.service. The second uses the systemctl is-enabled, which sets its exit status to 0 (zero) if the service is enabled or to nonzero otherwise. The || Boolean operator executes the echo command if systemctl returns a nonzero exit status (fails).
# ls /etc/systemd/system/.wants/ntpd.service ls: cannot access /etc/systemd/system/.wants/ntpd.service: No such file or directory # systemctl is-enabled ntpd.service || echo ntpd is not enabled ntpd is not enabled
The systemctl enable command causes a daemon to start when the system is booted. This command has no effect on the current state of the daemon. It creates the link that causes systemd to start ntpd when the system enters multiuser textual mode and, by inheritance, multiuser graphical mode. If you run the same command on a daemon that is controlled by a SysVinit script, it calls chkconfig (covered shortly).
# systemctl enable ntpd.service ln -s '/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'
As in the preceding example, the next two commands check whether the daemon will start when the system is booted.
$ ls /etc/systemd/system/.wants/ntpd.service /etc/systemd/system/multi-user.target.wants/ntpd.service $ systemctl is-enabled ntpd.service || echo ntpd is not enabled $
The chkconfig off and on commands correspond to the systemctl disable and enable commands. The messages the commands display when run on daemons systemd controls natively show they call systemctl. Because the chkconfig – –list option does not display the correct information for daemons controlled natively by systemd; you must use the preceding techniques to determine if such a daemon is enabled.
# chkconfig ntpd off Note: Forwarding request to 'systemctl disable ntpd.service'. rm '/etc/systemd/system/multi-user.target.wants/ntpd.service' # chkconfig ntpd on Note: Forwarding request to 'systemctl enable ntpd.service'. ln -s '/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'
optional
The preceding section discussed the systemctl enable command in terms of causing a daemon to start when the system boots. Most of the time this command works that way. However, the systemctl enable command can cause services to start based on various triggers, not just by the system booting.
For example, when bluetooth.service is enabled, it is controlled by the bluetooth device logic, which starts bluetooth.service when a bluetooth device is plugged in. If the bluetooth device is built in to the computer, this distinction is not important. However, if the bluetooth device is attached to a USB dongle, running systemctl enable means that in the future, the bluetooth service will be started as soon as the dongle is plugged in but not before.
In a similar vein, in future releases of Fedora the cupsd daemon will no longer be started when the system boots. Rather, running systemctl enable will only establish a communication socket for cupsd. The cupsd daemon will not start until a process tries to access it (when someone sends a job to the printer).
Changing the Current State of a Daemon
The systemctl stop command immediately stops a daemon from running. This command has no effect on whether the daemon starts when the system is booted. The following command works on the ntpd daemon, which is run natively by systemd. It will also work on a daemon systemd controls via a SysVinit script. You must always specify the .service part of the service name.
# systemctl stop ntpd.service
The preceding command stops the ntpd daemon. It displays no output, even if you mistype the name of the daemon. The following commands each verify the ntpd daemon is not running.
# systemctl status ntpd.service
ntpd.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntpd.service)
Active: inactive (dead) since Fri, 22 Apr 2011 08:50:59 -0700; 17ms ago
Process: 1036 ExecStart=/usr/sbin/ntpd -n -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/ntpd.service
# systemctl is-active ntpd.service
inactive
The systemctl status command shows an Active status of inactive (dead). The systemctl is-active command displays a status of inactive. You can also use ps –ef | grep ntpd to determine if the daemon is running.
The systemctl start command immediately starts a daemon running. This command has no effect on whether the daemon starts when the system is booted.
# systemctl start ntpd.service
The next two commands each show the daemon is running.
# systemctl status ntpd.service
ntpd.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntpd.service)
Active: active (running) since Fri, 22 Apr 2011 08:50:59 -0700; 33ms ago
Main PID: 1562 (ntpd)
CGroup: name=systemd:/system/ntpd.service
+ 1562 /usr/sbin/ntpd -n -u ntp:ntp -g
# systemctl is-active ntpd.service
active
The service stop, start, and status commands correspond the systemctl stop, start, and status commands. The messages the stop and start commands display show they simply call systemctl. You can use the service status command (or the systemctl status command) to display the status of a daemon.
# service ntpd stop
Stopping ntpd (via systemctl): [ OK ]
# service ntpd start
Starting ntpd (via systemctl): [ OK ]
# service ntpd status
ntpd.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntpd.service)
Active: active (running) since Fri, 22 Apr 2011 08:50:59 -0700; 102ms ago
Main PID: 1615 (ntpd)
CGroup: name=systemd:/system/ntpd.service
+ 1615 /usr/sbin/ntpd -n -u ntp:ntp -g
This excerpt is from the new 6th edition of the book, ‘A Practical Guide to Fedora and Red Hat Enterprise Linux’ by Mark G. Sobell, published by Pearson/Prentice Hall Professional, Aug. 2011, ISBN 0132757273, Copyright 2012 Mark G. Sobell. For more info, please visit http://sobell.com or the publisher site: www.informit.com/title/0132757273
- « first
- ‹ previous
- 1
- 2
- 3
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- RSS Feeds
- Home, My Backup Data Center
- What's the tweeting protocol?
- Readers' Choice Awards 2011
- Linux on Azure—a Strange Place to Find a Penguin
- Developer Poll
- Reply to comment | Linux Journal
4 hours 16 min ago - Reply to comment | Linux Journal
6 hours 49 min ago - Reply to comment | Linux Journal
8 hours 6 min ago - great post
8 hours 41 min ago - Google Docs
9 hours 3 min ago - Reply to comment | Linux Journal
13 hours 52 min ago - Reply to comment | Linux Journal
14 hours 38 min ago - Web Hosting IQ
16 hours 12 min ago - Thanks for taking the time to
17 hours 49 min ago - Linux is good
19 hours 47 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



Comments
Service units, is a daemon
Service units, is a daemon (service) systemd control, including, itself systemd control SysVinit script by systemd control. For example, systemd control ntpd daemon through ntpd.service service units.
I think that the system works
I think that the system works really good and I am sure that there will be a lot of users which will want to use it.
Asigurari Auto
Not "dérouillard"
Good article.
[It's not dérouillard (which sounds more like some anti-rusting thing) but «débrouillard» which has connotations of "muddling along".]
More usefully, Lennart Poettering has a good series of articles on his own blog about using systemd:
http://0pointer.de/blog/projects/why.html
http://0pointer.de/blog/projects/systemd-for-admins-1.html
http://0pointer.de/blog/projects/systemd-for-admins-2.html
http://0pointer.de/blog/projects/systemd-for-admins-3.html
http://0pointer.de/blog/projects/systemd-for-admins-4.html
http://0pointer.de/blog/projects/three-levels-of-off.html
http://0pointer.de/blog/projects/changing-roots
http://0pointer.de/blog/projects/blame-game.html
http://0pointer.de/blog/projects/the-new-configuration-files.html
http://0pointer.de/blog/projects/on-etc-sysinit.html
http://0pointer.de/blog/projects/instances.html
http://0pointer.de/blog/projects/inetd.html
Ok
Ok
Title Spell Check?
Excerpt not 'Exercpt'... good read though.