MESSAGE
| DATE | 2014-09-23 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] more systemd tutorials
|
https://www.linux.com/learn/tutorials/788613-understanding-and-using-systemd
Understanding and Using Systemd
Thursday, 18 September 2014 15:36 Carla Schroder |Exclusive
Submit to Linkedin Submit to Stumbleupon
Systemd components graphic
Image courtesy Wikimedia Commons, CC BY-SA 3.0
Like it or not, systemd is here to stay, so we might as well know what
to do with it.
systemd is controversial for several reasons: It's a replacement for
something that a lot of Linux users don't think needs to be replaced,
and the antics of the systemd developers have not won hearts and minds.
But rather the opposite, as evidenced in this famous LKML thread where
Linus Torvalds banned systemd dev Kay Sievers from the Linux kernel.
It's tempting to let personalities get in the way. As fun as it is to
rant and rail and emit colorful epithets, it's beside the point. For lo
so many years Linux was content with SysVInit and BSD init. Then came
add-on service managers like the service and chkconfig commands. Which
were supposed to make service management easier, but for me were just
more things to learn that didn't make the tasks any easier, but rather
more cluttery.
Then came Upstart and systemd, with all kinds of convoluted addons to
maintain SysVInit compatibility. Which is a nice thing to do, but good
luck understanding it. Now Upstart is being retired in favor of systemd,
probably in Ubuntu 14.10, and you'll find a ton of systemd libs and
tools in 14.04. Just for giggles, look at the list of files in the
systemd-services package in Ubuntu 14.04:
$ dpkg -L systemd-services
Check out the man pages to see what all of this stuff does.
It's always scary when developers start monkeying around with key Linux
subsystems, because we're pretty much stuck with whatever they foist on
us. If we don't like a particular software application, or desktop
environment, or command there are multiple alternatives and it is easy
to use something else. But essential subsystems have deep hooks in the
kernel, all manner of management scripts, and software package
dependencies, so replacing one is not a trivial task.
So the moral is things change, computers are inevitably getting more
complex, and it all works out in the end. Or not, but absent the ability
to shape events to our own liking we have to deal with it.
First systemd Steps
Red Hat is the inventor and primary booster of systemd, so the best
distros for playing with it are Red Hat Enterprise Linux, RHEL clones
like CentOS and Scientific Linux, and of course good ole Fedora Linux,
which always ships with the latest, greatest, and bleeding-edgiest. My
examples are from CentOS 7.
Experienced RH users can still use service and chkconfig in RH 7, but
it's long past time to dump them in favor of native systemd utilities.
systemd has outpaced them, and service and chkconfig do not support
native systemd services.
Our beloved /etc/inittab is no more. Instead, we have a
/etc/systemd/system/ directory chock-full of symlinks to files in
/usr/lib/systemd/system/. /usr/lib/systemd/system/ contains init
scripts; to start a service at boot it must be linked to
/etc/systemd/system/. The systemctl command does this for you when you
enable a new service, like this example for ClamAV:
# systemctl enable clamd-at-scan.service
ln -s '/usr/lib/systemd/system/clamd-at-scan.service'
'/etc/systemd/system/multi-user.target.wants/clamd-at-scan.service'
How do you know the name of the init script, and where does it come
from? On Centos7 they're broken out into separate packages. Many servers
(for example Apache) have not caught up tosystemd and do not have
systemd init scripts. ClamAV offers both systemd and SysVInit init
scripts, so you can install the one you prefer:
$ yum search clamav
clamav-server-sysvinit.noarch
clamav-server-systemd.noarch
So what's inside these init scripts? We can see for ourselves:
$ less /usr/lib/systemd/system/clamd-at-scan.service
.include /lib/systemd/system/clamd-at-.service
[Unit]
Description = Generic clamav scanner daemon
[Install]
WantedBy = multi-user.target
Now you can see how systemctl knows where to install the symlink, and
this init script also includes a dependency on another service,
clamd-at-.service.
systemctl displays the status of all installed services that have init
scripts:
$ systemctl list-unit-files --type=service
UNIT FILE STATE
[...]
chronyd.service enabled
clamd-at-.service static
clamd-at-scan.service disabled
There are three possible states for a service: enabled or disabled, and
static. Enabled means it has a symlink in a .wants directory. Disabled
means it does not. Static means the service is missing the [Install]
section in its init script, so you cannot enable or disable it. Static
services are usually dependencies of other services, and are controlled
automatically. You can see this in the ClamAV example, as clamd-at-.service
is a dependency of clamd-at-scan.service, and it runs only when
clamd-at-scan.service runs.
None of these states tell you if a service is running. The ps command
will tell you, or use systemctl to get more detailed information:
$ systemctl status bluetooth.service
bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib.systemd/system/bluetooth.service; enabled)
Active: active (running) since Thu 2014-09-14 6:40:11 PDT
Main PID: 4964 (bluetoothd)
CGroup: /system.slice/bluetooth.service
|_4964 /usr/bin/bluetoothd -n
systemctl tells you everything you want to know, if you know how to ask.
Cheatsheet
These are the commands you're probably going to use the most:
# systemctl start [name.service]
# systemctl stop [name.service]
# systemctl restart [name.service]
# systemctl reload [name.service]
$ systemctl status [name.service]
# systemctl is-active [name.service]
$ systemctl list-units --type service --all
systemd has 12 unit types. .service is system services, and when you're
running any of the above commands you can leave off the .service
extension, because systemd assumes a service unit if you don't specify
something else. The other unit types are:
Target: group of units
Automount: filesystem auto-mountpoint
Device: kernel device names, which you can see in sysfs and udev
Mount: filesystem mountpoint
Path: file or directory
Scope: external processes not started by systemd
Slice: a management unit of processes
Snapshot: systemd saved state
Socket: IPC (inter-process communication) socket
Swap: swap file
Timer: systemd timer.
It is unlikely that you'll ever need to do anything to these other
units, but it's good to know they exist and what they're for. You can
look at them:
$ systemctl list-units --type [unit name]
Blame Game
For whatever reason, it seems that the proponents of SysVInit
replacements are obsessed with boot times. My systemd systems, like
CentOS 7, don't boot up all that much faster than the others. It's not
something I particularly care about in any case, since most boot speed
measurements only measure reaching the login prompt, and not how long it
takes for the system to completely start and be usable. Microsoft
Windows has long been the champion offender in this regards, reaching a
login prompt fairly quickly, and then taking several more minutes to
load and run nagware, commercialware, spyware, and pretty much
everything except what you want. (I swear if I see one more stupid
Oracle Java updater nag screen I am going to turn violent.)
Even so, for anyone who does care about boot times you can run a command
to see how long every program and service takes to start up:
$ systemd-analyze blame
5.728s firewalld.service
5.111s plymouth-quit-wait.service
4.046s tuned.service
3.550s accounts.daemon.service
[...]
And several dozens more. Well that's all for today, folks. systemd is
already a hugely complex beast; consult the References section to learn
more.
References
Freedesktop.org systemd System and Service Manager
Here We Go Again, Another Linux Init: Intro to systemd
|
|
