SystemD. First impression.

ivandi · 10-18-2014, 06:24 PM

It was rainy day. In the morning I had two options: paint my garage floor or play with systemd.

The paint job sucks.

I already have my PAMified Slackware-current so adding systemd wasn't that hard. Here is the preliminary slackbuild:

http://www.bisdesign.ca/ivandi/slackware/SystemD/

What can I say ?!?

It is different.
It is fast. I mean it.
It is huge.
It works.

Basically I built the systemd package, installed it and rebooted.
For my great surprise there was no any kernel panic. The system started really fast I was prompted to enter the locale. I skipped it and the boot continued to the login prompt on a single tty. However there were some error messages:

systemd-journald failed to start because of missig machine_id ?!?
systemd-logind failed because of missing dbus.socket and dbus.service.

I put "LANG=en_US.UTF-8" in /etc/locale.conf
systemd-machine-id-setup fixed the problem with the missig machine_id.
I recompiled dbus and that fixed the logind problem.

To make the wifi network setup work like in Sslackware's rc.inet1 I had to modify the wpa_supplicant.SlackBuild to put some services in place. The supplicant supports systemd by default, just the package doesn't ship the services. Setting up the network is really simple:

Code:

[Match]
Name=wlan0

[Network]
DHCP=yes

Recompiled XDM. It supports systemd too. No need to modify the slackbuild.

Finaly I was able to login in the default graphical.target w/o any error and to have network connection working. For my tests I use a minimal setup so no fancy network manager or kdm here.

Now I can understand why systemd takes over the Linux world by storm. No more boot, network, start stop or whatever scripts. systemctl rules them all.
It "slices" the system resources in a beautiful way.

systemd-cgls:

Code:

|-1 /sbin/init
|-system.slice
| |-dnsmasq.service
| | `-350 /usr/sbin/dnsmasq
| |-systemd-resolved.service
| | `-346 /lib/systemd/systemd-resolved
| |-systemd-logind.service
| | `-319 /lib/systemd/systemd-logind
| |-systemd-networkd.service
| | `-318 /lib/systemd/systemd-networkd
| |-dbus.service
| | `-316 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfi...
| |-systemd-timesyncd.service
| | `-246 /lib/systemd/systemd-timesyncd
| |-systemd-udevd.service
| | `-241 /lib/systemd/systemd-udevd
| |-systemd-journald.service
| | `-214 /lib/systemd/systemd-journald
| `-system-wpa_supplicant.slice
|   `-wpa_supplicant@wlan0.service
|     `-314 /usr/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-wla...
`-user.slice
  |-user-1000.slice
  | |-session-2.scope
  | | |-17702 /bin/login --
  | | |-17717 -bash
  | | |-18122 -bash
  | | |-18138 xinit /home/ivandi/.xinitrc -- /usr/bin/X :0 -auth /home/ivandi...
  | | |-18139 /usr/bin/X :0 -auth /home/ivandi/.serverauth.18122
  | | |-18146 fluxbox
  | | |-18152 dbus-launch --sh-syntax --exit-with-session
  | | |-18153 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --s...
  | | |-18175 xterm
  | | |-18177 bash
  | | `-18180 systemd-cgls
  | `-user@1000.service
  |   |-17713 /lib/systemd/systemd --user
  |   `-17715 (sd-pam)
  `-user-0.slice
    |-session-1.scope
    | |-375 /bin/login --
    | `-381 -bash
    `-user@0.service
      |-377 /lib/systemd/systemd --user
      `-379 (sd-pam)

I wrote my first service for dnsmasq and it was easy:

dnsmasq.service:

Code:

[Unit]
Description=A lightweight DHCP and caching DNS server
After=network.target
Documentation=man:dnsmasq(8)

[Service]
Type=forking
ExecStart=/usr/sbin/dnsmasq
ExecReload=/bin/killall -HUP dnsmasq

[Install]
WantedBy=multi-user.target

So my conclusion after a few hours of playing with systemd is sort of:

I like it when it works, but don't call me if it brakes.

Cheers

metaschima · 10-18-2014, 06:39 PM

As long as you have tried it and posted about it, why not do a boot speed benchmark ? This seems to be the main thing you and others are after.

Make sure to keep them as fair as possible, don't make one do more than the other.

speck · 10-18-2014, 06:41 PM

Would you mind posting the output of the following command after you've started your GUI environment? I'm curious about the memory/cpu usage of the various systemd components.

Code:

ps axco rss,pcpu,command --no-header --sort -rss,-pcpu | grep -v ' 0  0.0'

ReaperX7 · 10-18-2014, 06:53 PM

Flush your journal regularly because if it corrupts it will slow the boot to a crawl. There's no fix for it, so if it corrupts, dump the journal and hope for the best.

You honestly can should give uselessd a try as well.

Also do not disable the networkd daemon or it will destroy your networking. Be advised it doesn't have IPv6 support.

ivandi · 10-18-2014, 07:32 PM

Quote:

Originally Posted by speck

Would you mind posting the output of the following command after you've started your GUI environment? I'm curious about the memory/cpu usage of the various systemd components.

Code:

ps axco rss,pcpu,command --no-header --sort -rss,-pcpu | grep -v ' 0  0.0'

Code:

bash-4.3$ ps axco rss,pcpu,command --no-header --sort -rss,-pcpu | grep -v ' 0  0.0'
292056 65.4 firefox
34360  4.4 X
11152  0.1 systemd-journal
 6592  0.7 fluxbox
 4144  0.1 xdm
 3956  0.2 systemd
 3920  1.4 xterm
 2876  0.0 wpa_supplicant
 2212  0.0 systemd
 2108  0.0 (sd-pam)
 2012  0.1 bash
 1960  0.2 systemd-udevd
 1656  0.0 systemd-network
 1632  0.0 systemd-logind
 1568  0.0 dbus-daemon
 1564  0.0 systemd-resolve
 1460  0.0 xdm
 1348  0.0 systemd-timesyn
  992  0.0 ps
  964  0.0 grep
  916  0.0 dnsmasq
  900  0.0 agetty
  664  0.0 dbus-launch
  664  0.0 dbus-daemon

ivandi · 10-18-2014, 07:58 PM

Quote:

Originally Posted by metaschima

As long as you have tried it and posted about it, why not do a boot speed benchmark ? This seems to be the main thing you and others are after.

Make sure to keep them as fair as possible, don't make one do more than the other.

I don't think the cheap talk has some place here. And I am not willing to do any boot time benchmarks because I simply don't care about them.

I found this in the log (journal) after the last boot:

Code:

-- Userspace start-up required 127012 microseconds.

For me it doesn't mean anything. This is a minimal setup system. Anyway, it boots much faster than the same setup with sysvinit.

Cheers.

ReaperX7 · 10-18-2014, 08:44 PM

Minimized down, any init system booting only the bare essentials, will all work at the same speed. Speed of init and boot is irrelevant.

The problem comes when you start loading the system services. In linear boot, yes it will be slower, but it will also be more accurate as systems and dependencies are chain loaded. With parallel boot, you have to create a dependency tree check and load setup chain for each service branch to check and load for other dependencies. In fact, parallel boot is only more complex than linear and offer no real benefits to boot. As long as services are up, running, and can be managed effectively by an administrator properly using a status check, using alternative init systems to sysvinit, is purely aesthetics. Even automated service management is fickle at best in practice, and an attentive administrator can do the same work as an automated toolkit.

ivandi · 10-18-2014, 09:08 PM

Quote:

Originally Posted by ReaperX7

Flush your journal regularly because if it corrupts it will slow the boot to a crawl. There's no fix for it, so if it corrupts, dump the journal and hope for the best.

You honestly can should give uselessd a try as well.

Also do not disable the networkd daemon or it will destroy your networking. Be advised it doesn't have IPv6 support.

Yeah, IMO the binary format log(journal) sucks. After the gconf/dconf/xfconf registries we'll have an event log too. And the entire systemd looks like svchost.exe.

"Those who do not understand Unix are condemned to reinvent it, poorly." I think we are there.

I am not willing to try uselessd, sucklessd or whateverd. I have some spare time these days and I want to try what the mainstream provides. Sooner than later we'll be forced to use it. More than 50% of Slackware users are KDE fan-boys.

Cheers

ivandi · 10-18-2014, 09:15 PM

Quote:

Originally Posted by ReaperX7

Even automated service management is fickle at best in practice, and an attentive administrator can do the same work as an automated toolkit.

No offense. It seems you are young enough for not getting the point. No one needs an attentive administrator nowadays. The automated toolkit is good enough and much cheaper.

Cheers

frankbell · 10-18-2014, 10:37 PM

One of the fellows in my LUG is a sysadmin who currently is using RHEL in his network.

He says that SystemD is great . . . when it works. He says that, when it doesn't work and needs to be debugged, it is a nightmare.

ReaperX7 · 10-19-2014, 12:04 AM

Uselessd is systemd, just stripped bare and devoid of useless garbage. All it is, is the init and cgroups control matrix. I have a small test system in VMware running it. It has a few issues still but it works better than the native project by giving you the admin back control of your system.

As for service monitoring, I have a script I created to run status checks on my server in cronjobs, output a log file each half hour and email me the log.

elvis4526 · 10-19-2014, 01:58 AM

" Yes, it is written systemd, not system D or System D, or even SystemD. "
http://www.freedesktop.org/wiki/Software/systemd/

Did ANYBODY here even bothered to at LEAST read the homepage of systemd ?

kikinovak · 10-19-2014, 02:30 AM

Quote:

Originally Posted by elvis4526

" Yes, it is written systemd, not system D or System D, or even SystemD. "
http://www.freedesktop.org/wiki/Software/systemd/

Did ANYBODY here even bothered to at LEAST read the homepage of systemd ?

There's been a similar, erm, controversy on the Elementary OS forum. The developers were stating their system was written "elementary", and not "Elementary OS". Despite this statement, everybody continues using the "wrong" orthography. That's what you get when you desperately try to be original.

Mark Pettit · 10-19-2014, 03:11 AM

The thing is that systemd is a solution looking for a problem.

And I have no problems. My servers, which reboot maybe twice a year take 50 to 75 seconds to boot and I'm quite happy with that. I see no reason to disrupt them with such invasive software for marginal "benefits".

My laptop resumes from suspend in about 5 seconds. No reason to "improve" on that either.

While I have no requirements for GUI software on my servers, I'm very happy to run a GUI desktop on my laptop - so I'm not a luddite and anti-technology or anti-improving Unix - it just needs to be done when it's clearly beneficial. The rewards must far outweigh any possible downsides. Clearly this is NOT the case with systemd.

But I'm sure that Pat will make the right choice here. Whatever that may be. If he does choose to go systemd, then I will believe that it's been properly evaluated and will have stood up to Slackware requirements and I'll happily use it - just like the rest of Slackware.

Randicus Draco Albus · 10-19-2014, 03:30 AM

Quote:

If he does choose to go systemd, then I will believe that it's been properly evaluated and will have stood up to Slackware requirements

Or he had no choice, because systemd permeated the system to the point that the system could not run without it. (There are usually at least two scenarios for every situation.)