Slashdot Mirror
Ubuntu 15.04 Released, First Version To Feature systemd
jones_supa writes: The final release of Ubuntu 15.04 is now available. A modest set of improvements are rolling out with this spring's Ubuntu. While this means the OS can't rival the heavy changelogs of releases past, the adage "don't fix what isn't broken" is clearly one 15.04 plays to. The headline change is systemd being featured first time in a stable Ubuntu release, which replaces the inhouse UpStart init system. The Unity desktop version 7.3 receives a handful of small refinements, most of which aim to either fix bugs or correct earlier missteps (for example, application menus can now be set to be always visible). The Linux version is 3.19.3 further patched by Canonical. As usual, the distro comes with fresh versions of various familiar applications.
It wasn't added. It has been there for a while. What's changed is that this time it's the default init.
How much wood would a woodchopper chop if a woodchopper would chop wood?
Debian Jessie with MATE is very good too. Should be released tomorrow AFAIK.
Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.
Er quite, though I was specifically referring to restarting PulseAudio, which takes a second not the entire computer. If the base underlying init process needs a restart, well, that's a different kettle of fish.
FWIW, the only time I restart systemd is to update the kernel, or I guess systemd itself (though the kernel changes more often and thus I can usually lump the latter in with the former). If you do live-patch your kernel, then you can do the same with systemd - it has a command to re-exec itself while preserving state.
I'm sure it isn't perfect, but it is as robust as anything else I've used on Linux. There are fairly few daemons that I've never seen need a restart sometime in the last 10 years.
> overly complex to the point of being nearly undebuggable
Even worse is the fact that it ignores exit statuses and swallows stderr which makes it impossible to troubleshoot problems. While starting a process fails, systemd typicaly deletes all traces of why it happened.
It is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.
What more debug do you need that other inits are providing?
System V init scripts don't have a policy against syslog and stdout. If a process outputs to stderr with a standard init script, then you see it on the screen. You can debug problems. With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged. It is simply sent to /dev/null. The creator of systemd admitted he doesn't get the concept of stderr. It is an important one, and his policy makes it nearly impossible to debug startup problems. That is why systemd is useless for systems with nontrivial startup scripts, which is exactly what it is being sold as solving so that makes it broken by design. It does not do what it is being sold to do.
Here's a script that reproduces this flaw in systemd that was originally posted to a systemd bug that was of course deleted and ignored:
# cat
CentOS Linux release 7.0.1406 (Core)
# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target
[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh
[Install]
WantedBy=multi-user.target
EOF
# cat /root/broken_systemd.sh
#!/bin/bash
echo "Example systemd service"
echo "Error that should not be thrown away" >&2
exit 1
EOF
# chmod +x /root/broken_systemd.sh
# systemctl start broken_systemd ; echo $?
0
# journalctl -u broken_systemd
Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.
> journalctl -f
Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.
You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way.
Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily.
systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.
It's not that a single thing was broken, it's that the combined deficiencies were impacting software management. It's an evolutionary dead end. Systemd is being actively maintained and documented and implemented in ways that allow it to better interact with the free software ecosystem.
At its core, it includes a lot of fixes for classic init that you would have to implement separately if you use classic init.
Services are easily manageable.
Booting is compartmentalized to allow for easy debugging(Items report success or failure individually, in order, and with consistency).
Intrinsic functions and customizations are separated.
Items do not necessarily rely on other items' dependency lists to configure themselves in the startup queue.
System management is easier if services are manageable through a homogeneous interface. This effect trickles down to service creation, and then to package management. The distribution manages the packages, so it's in their best interest to pick an init that will help everything run smoothly.
If the qualities of classic init are critical to your use-case, there are always other distributions available.
Who keeps modding these posts up? Using "journalctl -f" to view output from stderr to debug why daemons aren't starting is a feature I use often as part of my job. If there was ever a version of systemd that didn't log stderr, it was a short lived bug.
What fucking idiot modded this informative?
Apr 24 10:52:06 u1504 systemd[1]: Starting Broken systemd example...
Apr 24 10:52:06 u1504 systemd[1]: Started Broken systemd example.
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Example systemd service
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Error that should not be thrown away
Apr 24 10:52:06 u1504 systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 24 10:52:06 u1504 systemd[1]: Unit broken_systemd.service entered failed state.
# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target
[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh
[Install]
WantedBy=multi-user.target
EOF
Note that you are using the default Type=simple, where systemd considers the program started as soon as the child process has execve()d. So the exit code of systemctl start will naturally be 0, because Type=simple by definition doesn't wait for the process.
Depending on what you want to achieve, you will want to set a different Type=. For example, if you set Type=oneshot, systemctl start will return a proper error exit code (because it will wait for the process to finish before considering the unit's status).
But even in your example, when the process exits later on, the unit's status (see systemctl status or systemctl --failed) will be considered failed, because then systemd will detect the error exit.
This is all nothing new and documented.
# journalctl -u broken_systemd
Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.
I don't know about RHEL7, never useed that, but on Debian 8 your exact unit gives me the following (anonymized) output:
DATE TIME HOSTNAME broken_systemd.sh[PID]: Example systemd service
DATE TIME HOSTNAME broken_systemd.sh[PID]: Error that should not be thrown away
DATE TIME HOSTNAME systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
DATE TIME HOSTNAME systemd[1]: Unit broken_systemd.service entered failed state.
And in contrast to sysvinit, where the output of init scripts might flash on the console before being replaced by something else (too fast to see), systemd actually logs them and they are now available for later viewing. I consider the handling of stdout/stderr of services by systemd a huge step up compared to sysvinit - I've seen TONS of init scripts that start daemons with >/dev/null 2>&1 or so, because otherwise the daemon would clutter the console with messages, and those messages just got thrown away before. Now they can actually be logged.
it ignores exit statuses and swallows stderr
No, it doesn't. Exit statuses are the means by which it detects and reports that a service started successfully or failed. Stderr is recorded in both the journal and syslog messages file. I verified both on CentOS 7 and Fedora 21 a moment ago.
Well, I also tried it and could not reproduce those results on either Fedora 21 or CentOS 7. Both systems logged stderr to both the journal and the syslog messages file.
The old init system did not log stderr. If you didn't see an error printed to a tty, it was lost. systemd is actually an improvement in exactly the aspect that ACs complain about through this thread.
I suffered through Ubuntu Unity on my laptop for one month until I did sudo apt-get install xubuntu-desktop. I wonder what'll break in a year once I upgrade from what amounts to Xubuntu 14.04 LTS to 16.04.
Thanks to systemd, every time I get a kernel update, I can look forwards to spending 4 hours trying to get the box to boot again. EVERY freaking time!
In Fedora 21, "single" boot mode doesn't even present a the filesystem you need to repair. I finally had to resort to a rescue CD. Not all my machines have CD drives attached anymore.