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.
> 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.