Wednesday, April 17, 2013

Systemd vs. SysV Runlevels: Why's the Network Down?

I recently installed Fedora 17 (the Beefy Miracle) on a server.  The server hosts KVM virtual machines and Yum repositories, and provides PXE boot services. It's a pure network server and so there's no need for a graphical desktop.

For those you familiar with the traditional Unix SysV runlevels, you can probably guess which one I wanted to set as the default: three. Runlevel 3 is typically called "multi-user" with the implication that networking is enabled (for users to log in with) and no console GUI is provided.

Runlevels are pretty easy to understand. The /etc/inittab file sets a default runlevel. The runlevels are basically a directories full of scripts (actually, symlinks to scripts) that run in a certain order.  Each one does its part to bring the system up in a repeatable way.

Starting with Fedora 15, the SysV init scripts have been slowly phasing out in favor of systemd "targets". If you've booted anything newer than F16 on a computer lately -- even a dog slow box -- you'll notice that it boots way faster than the older releases. That's largely because of the efficient and parallel nature of systemd.

Anyway, it took me a while to get my head around this new beast. It's more complex than ol' SysV init. But the developers did do some things to smooth the transition, one of which was to keep the concept of runlevels around.

I knew that the "target" concept was similar to runlevels.  So, not wanting to dive too deep into systemd at the time, I Googled around a bit and found with this simple recipe:
Q: How do I change the default runlevel to boot into?
A: The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:
# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target
or
# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

I wanted runlevel 3, so I chose the multi-user.target answer.  Easy enough.

I went on with my work and never actually tested this target.  When the server came back up after a power outage, the network was down.  After poking around on the console, I realized that the network service wasn't running, so I started it.

systemctl start network.service

Then I dug into why it wasn't running in the first place and found that the network service wasn't even enabled. So I took care of that.

systemctl enable network.service

I verified that all was well by rebooting.

So, WTF? I don't know why networking isn't enabled in "multi-user" mode. Do you know?

No comments:

Post a Comment