talks: add systemd: the good parts (#368)
Signed-off-by: Christine Dodrill <me@christine.website>
This commit is contained in:
GitHub
parent
95bfc64097
commit
062aac0903
|
|
@ -0,0 +1,258 @@
|
||||||
|
---
|
||||||
|
title: "systemd: The Good Parts"
|
||||||
|
date: 2021-05-16
|
||||||
|
slides_link: https://docs.google.com/presentation/d/1a0XaGu87xUcpQQVLkrnXKoKrdpN1ObiPrG9aGYVMw7k/edit?usp=sharing
|
||||||
|
---
|
||||||
|
|
||||||
|
# systemd: The Good Parts
|
||||||
|
|
||||||
|
[Video](https://youtu.be/TJdKXq197Qk)
|
||||||
|
|
||||||
|
<center><iframe width="560" height="315" src="https://www.youtube.com/embed/TJdKXq197Qk" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe></center>
|
||||||
|
|
||||||
|
The slides link will be at the end of the post.
|
||||||
|
|
||||||
|
Hello, I'm Xe and today I'm going to do a talk about systemd. More specifically
|
||||||
|
the good parts of systemd. This talk is going to go fast because there's a lot
|
||||||
|
of material to cover and the notes are going to be on my website. I have been an
|
||||||
|
Alpine user for almost a decade and it's one of my favorite linux distributions.
|
||||||
|
|
||||||
|
The best things in life come with disclaimers and here are the disclaimers for this talk:
|
||||||
|
- This talk may contain opinions. These opinions are my own and not necessarily
|
||||||
|
the opinions of my employer.
|
||||||
|
- This talk is not evangelism. This talk is intended to show how green the grass
|
||||||
|
is on the other side and how Alpine can benefit from these basic ideas.
|
||||||
|
- This talk also contains images of cartoon marine animals.
|
||||||
|
|
||||||
|
[What is systemd?](conversation://Mara/hmm)
|
||||||
|
|
||||||
|
When doing a talk about a thing I find it helps to start with a good definition
|
||||||
|
of what that thing is. Given this talk is about systemd let's start with what
|
||||||
|
systemd is.
|
||||||
|
|
||||||
|
<center>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
</center>
|
||||||
|
|
||||||
|
systemd is a set of building blocks that you can use to make a linux system.
|
||||||
|
This diagram covers most of the parts of systemd. There is everything from
|
||||||
|
service management to log management to boot time analysis, network
|
||||||
|
configuration, and user logins; but we're only going to cover a tiny fraction of
|
||||||
|
this diagram. At a high level systemd provides a common set of tools that you
|
||||||
|
can build a linux system with; kind of like lego bricks. It does just manage
|
||||||
|
services but it does more than just service management.
|
||||||
|
|
||||||
|
Something else that's useful to ask is "why does systemd exist?" Well, looking
|
||||||
|
back at that diagram, computers are actually fairly complicated. There's a lot
|
||||||
|
going on over here. There's log management, there's disk management, there's
|
||||||
|
service sequencing, network configuration, containers user sessions and most
|
||||||
|
importantly all of these things need to happen in order or bad things can
|
||||||
|
happen. I mentioned that systemd is more than just a service service manager
|
||||||
|
because it has optional components that manage things like dns resolution,
|
||||||
|
network devices, user sessions, and user level services among other things.
|
||||||
|
|
||||||
|
One of the big differences between systemd and other things like OpenRC is that
|
||||||
|
systemd is a very declarative environment. In declarative environments you
|
||||||
|
specify what you want and the system will figure out what it needs to do to get
|
||||||
|
there. In an imperative environment you specify all of the steps you need to do
|
||||||
|
to get there. It's the difference between writing a sql statement and a for
|
||||||
|
loop.
|
||||||
|
|
||||||
|
So, pretend that this somewhat realistic scenario is happening to you: it's 4:00
|
||||||
|
am you just got a panicked call from someone at your company that the website is
|
||||||
|
down. You log into a server and you want to see if the website is actually down
|
||||||
|
or if it's just dns. You probably want to know the answers to these basic
|
||||||
|
questions:
|
||||||
|
|
||||||
|
- Does the service manager think your service is running?
|
||||||
|
- How much ram is it using?
|
||||||
|
- Does it have any child processes?
|
||||||
|
- Has it reported it is healthy?
|
||||||
|
- How much traffic has it used?
|
||||||
|
- What are the last few log lines?
|
||||||
|
- If you need to reboot the server right now for some reason, will that service
|
||||||
|
come back up on reboot?
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
systemd includes a tool called systemctl that allows you to query the status of
|
||||||
|
services as well as start and stop them; but for right now we're going to look
|
||||||
|
at the systemctl status subcommand. Here is the output for the systemctl status
|
||||||
|
command for the service powering christine.website. So let's go down the list:
|
||||||
|
|
||||||
|
- Is the service running? If you look at the red box right there you can see
|
||||||
|
that it says say the service has been running for nine hours.
|
||||||
|
- How much ram is it using? If you look at the red box there it says it's using
|
||||||
|
about 200 megs of ram.
|
||||||
|
- How many child processes are there if you look at the red box it'll show you
|
||||||
|
all of the processes in the service's cgroup. In this case we'll see that
|
||||||
|
there's just one process.
|
||||||
|
- How much network traffic has it been using? If we look here in the red box you
|
||||||
|
can see it's had about a megabyte of traffic in and somewhat less than a
|
||||||
|
megabyte of traffic out. My website serves everything over a unix socket and
|
||||||
|
those numbers aren't reflected here but it's actually much higher.
|
||||||
|
- At the bottom we can see the last few log lines. These are just random
|
||||||
|
requests that people make to my blog.
|
||||||
|
|
||||||
|
[Where did it get those logs from?](conversation://Mara/hmm)
|
||||||
|
|
||||||
|
If you haven't seen all of this in action before you might be wondering
|
||||||
|
something like "Wait, where did it get those logs from?"
|
||||||
|
|
||||||
|
I mentioned systemd does more than just start services. systemd has a common log
|
||||||
|
sink called the journal. Logs from the kernel, network devices, services, and
|
||||||
|
even some other system sources that you may not think are important
|
||||||
|
automatically get put into the journal. It's similar to Windows event logs or
|
||||||
|
the console app in macOS except it's implicit instead of explicit (Windows and
|
||||||
|
macOS make you use some weird logging calls to make sure that log lines actually
|
||||||
|
get in there, but systemd will capture the standard output, standard error and
|
||||||
|
syslog for every service managed by systemd). Something neat about the journal
|
||||||
|
is that it lets you tail the logs for the entire system with one command:
|
||||||
|
`journalctl -f`. Here's that command running on a server of mine:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
There's a lot more to the journal involving structured logging, automatically
|
||||||
|
streaming the logs to places, and advanced filtering based off of different
|
||||||
|
units, services, or other arbitrary fields; however that is out of scope for
|
||||||
|
this talk. The important part is that it has support for that in case you
|
||||||
|
actually need it.
|
||||||
|
|
||||||
|
Now this is all great, and you might be think asking yourself "well, yeah, this
|
||||||
|
stuff is cool; but how does Alpine fit into this? Alpine can't run systemd
|
||||||
|
because systemd is glibc specific." However we're not talking about systemd
|
||||||
|
directly, we're talking about the philosophies involved and the truth is that
|
||||||
|
this kind of experience is what people already have elsewhere. By not having
|
||||||
|
something competitive Alpine is less and less attractive for newer production
|
||||||
|
deployments.
|
||||||
|
|
||||||
|
Now there's at least four classes of benefits for systemd and I'm going to break
|
||||||
|
them down into the following groups:
|
||||||
|
- developers
|
||||||
|
- packagers
|
||||||
|
- system administrators
|
||||||
|
- users
|
||||||
|
|
||||||
|
In general people that are developing services that run on systemd get the following benefits:
|
||||||
|
|
||||||
|
- Predictability. systemd configuration files are declarative rather than
|
||||||
|
imperative. You declare units instead of imperatively building up init
|
||||||
|
scripts. Options are declared and enforced by the service manager. This makes
|
||||||
|
it a lot easier to review changes for correctness.
|
||||||
|
- Portability. when setting up a service with systemd there's only one syntax to
|
||||||
|
learn across 15 plus different distributions. This means that you don't have
|
||||||
|
to maintain a giant pile of hacks to make the program just start consistently
|
||||||
|
across different distributions and you can only care about the systemd unit
|
||||||
|
that will make everything happen for you. Before systemd was widespread every
|
||||||
|
distribution had their own unique special snowflake configuration for init
|
||||||
|
systems and it really just wasn't that nice to deal with. Ubuntu had different
|
||||||
|
opinions from Debian, Debian and opensuse had different opinions, and centos
|
||||||
|
was way out in the weeds and it just became hard to do this consistently
|
||||||
|
across distributions. Something declarative like systemd makes doing it across
|
||||||
|
distributions a lot easier by comparison.
|
||||||
|
- One of the other big things that it has is a api for controlling things with
|
||||||
|
dbus. Now, say what you will about dbus but dbus does have some very rich
|
||||||
|
introspection capabilities, as well as giving you the ability to integrate
|
||||||
|
with system services at a level that more closely resembles what you get on
|
||||||
|
windows or macOS (or even something like sel4 with microkernel message
|
||||||
|
passing). You don't have to shell out to commands and pray the output format
|
||||||
|
didn't change. You don't have to do some weird calls to unix sockets. It uses
|
||||||
|
standard apis and allows you to integrate things more tightly with the system.
|
||||||
|
Gnome for example uses systemd to trigger suspend and shutdown, as well as
|
||||||
|
having a way a little gui to query the systemd journal. Server software can
|
||||||
|
subscribe to units being started for auditing purposes and such.
|
||||||
|
|
||||||
|
Packagers or people that are putting software into packages get the following benefits:
|
||||||
|
|
||||||
|
- It is a lot easier to write a systemd unit than it is to write an OpenRC
|
||||||
|
script. systemd units are very bland and boring, they look like ini files. It is
|
||||||
|
going to be pretty obvious that it just does what it does and there's nothing
|
||||||
|
special going on. And because of this declarative syntax it makes human error
|
||||||
|
a lot more obvious and it is a lot easier for other humans to review.
|
||||||
|
- Now, don't get me wrong, shell scripts for service definitions have gotten
|
||||||
|
us a very long way and are likely to stay around for a very long time (I
|
||||||
|
actually use shell scripts with most of my systemd services to do weird things
|
||||||
|
with environment variables for configuration). However, shell scripting is a
|
||||||
|
very, very subtle art and it is very easy to mess up and do things that are
|
||||||
|
very unpredictable if you are not extremely careful. The declarative syntax of
|
||||||
|
systemd removes the ability for you to mess up formatting shell scripts; or at
|
||||||
|
the very least it isolates the flaws of the shell script to the exact service
|
||||||
|
running and not things like the user that the service is running under.
|
||||||
|
|
||||||
|
system administrators of systemd systems also get the following benefits:
|
||||||
|
|
||||||
|
- systemctl status and a lot of other parts of systemctl let you see what the
|
||||||
|
system or an individual service is doing without having to wonder if it's
|
||||||
|
actually working or not. In general the lazy the lazy thing is the thing that
|
||||||
|
you want to optimize for because people are distracted. There is a lot going
|
||||||
|
on sometimes and if you optimize it so that the easiest thing to do is the
|
||||||
|
correct thing then it is a lot easier to deal with when you have a distracted
|
||||||
|
operator. systemd is set up so that it's hard to do the wrong thing. It is
|
||||||
|
hard to have logs go anywhere about the system journal. It is hard to write a
|
||||||
|
unit that doesn't tell you if the service is actually running or not. And it
|
||||||
|
makes it so that the path of least resistance will do most of what you want.
|
||||||
|
- Sometimes system administrators have opinions that are different than the
|
||||||
|
opinions of the packager. Sometimes you need to change environment variables
|
||||||
|
for http proxies or something and sometimes you believe the packager has
|
||||||
|
different opinions than you do about how something should be run. In OpenRC
|
||||||
|
you'd have to make a copy of the init script, make your changes, and then hope
|
||||||
|
those changes don't get blown away when the package updates. systemd has a
|
||||||
|
first-class mechanism for doing this called drop-in units that allow you to
|
||||||
|
customize parts of a systemd service so that you can override exactly what you
|
||||||
|
need to (and only that) and systemd will turn the all of those into one big
|
||||||
|
logical unit and actually go off and run that. This has been very useful in
|
||||||
|
practice.
|
||||||
|
- Another thing that is kind of endemic to sysvinit and OpenRC systems is the
|
||||||
|
fact that unless you are careful and configure it right cron job output will
|
||||||
|
just go to nowhere and there is not really an easy way to figure out if a cron
|
||||||
|
job actually ran and if it errored or if it did exactly what you wanted. If I
|
||||||
|
recall there was actually an entire small startup that was formed around just
|
||||||
|
alerting for cron jobs that were not doing what they should be doing. systemd
|
||||||
|
changes this systemd because all of the logs are in the journal. If you set up
|
||||||
|
a systemd timer (which is the systemd land equivalent to a cron job) all of
|
||||||
|
the output for the service associated with that timer gets put into the
|
||||||
|
journal and you can see exactly what went wrong so you can go off and fix it.
|
||||||
|
This has saved me so much time and headache trying to do this stuff manually.
|
||||||
|
- Another thing that you can do is you can group services together with targets
|
||||||
|
which are kind of like named runlevels. Targets let you specify the difference
|
||||||
|
between the system booting the network stack is configured and all of the
|
||||||
|
services needed for your app are running. You can get a list of dependencies
|
||||||
|
from systemd for any service and you can also use that to help you plan
|
||||||
|
incident response, so it is more difficult to have hidden dependencies.
|
||||||
|
|
||||||
|
As far as users go:
|
||||||
|
- systemd is not limited to just managing system level services systemd can also
|
||||||
|
manage user services with systemd user mode. I use this on my Linux system in
|
||||||
|
order to have a couple services running in the background querying for weather
|
||||||
|
or a couple other api calls to put them into my status bar on my tiling window
|
||||||
|
manager (sway). I have another one that runs emacs in server mode so that I can
|
||||||
|
have one giant emacs session that will automatically start on login. I can put
|
||||||
|
hundreds and hundreds of buffers in there and not have to worry about it. I can
|
||||||
|
spawn new emacs frames instantly, it's really beautiful.
|
||||||
|
- You can also query all of the system journal logs as a normal user and you
|
||||||
|
don't have to sudo up and go into the logs folder. So if you just want to take
|
||||||
|
a quick look at something, you don't have to type in your password or hit a
|
||||||
|
yubikey press or whatever you have configured.
|
||||||
|
|
||||||
|
[I hope Alpine ends up with something similar!](conversation://Mara/happy)
|
||||||
|
|
||||||
|
I really hope alpine comes up with something similar to systemd. Alpine can
|
||||||
|
really benefit from a tightly integrated service manager that does at least some
|
||||||
|
of the things that systemd does. Declarative really is better than imperative
|
||||||
|
because declarative is easier for distracted operators.
|
||||||
|
|
||||||
|
People get distracted. It happens, and when distracted people do things it can
|
||||||
|
sometimes have bad consequences. So if we make the tools powerful, but
|
||||||
|
implicitly correct, then it will just be a lot better overall and users will
|
||||||
|
have a lot less worry involved.
|
||||||
|
|
||||||
|
On that note we are very close to hitting time so here's my shout outs to people
|
||||||
|
who either help make this talk happen or I think are cool.
|
||||||
|
|
||||||
|
if you have any questions please feel free to ping me on twitter, in the irc
|
||||||
|
room, or on the compact page on my website. I enjoy these kinds of questions and
|
||||||
|
I openly welcome you to ask them.
|
||||||
|
|
||||||
|
Thank you, have a good day.
|
||||||
Loading…
Reference in New Issue