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.
Systemd, eh? I predict that this thread will be filled with sensible and rational comments.
Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.
I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".
SJW n. One who posts facts.
One more requirement: explain how to debug/trace exactly what systemd is doing without recompiling systemd and adding specific printf() statements everywhere.
Because that's what's missing from systemd at the moment.
the adage "don't fix what isn't broken" is clearly one 15.04 plays to.
Uh huh...
systemd [...] replaces the inhouse UpStart init system.
Hmm.
systemd is Roko's Basilisk.
Gnome Shell is no better than Unity. Both are unusable user interfaces. Shame on those self-appoint user interface experts (more like non-experts) for taking a dump on its existing users.
Long live Ubuntu MATE! Ubuntu MATE has made Linux actually enjoyable to use again.
if I had mod points, I'd mod you as troll.
its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.
the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.
see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!
what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE). faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?
basically, the linux distros have been 'google-fucked'. I use that term to mean that some young snotnose didn't have anything better to do with his time and decided to royally break things and redo them, just because he thought it was a 'good idea'. but clearly didn't think it all the way thru and just wanted it because he just wanted it! typical google style; break things and trash all the old history of how things WERE done because, well, we just CANT LEAVE WORKING THINGS ALONE!
--
"It is now safe to switch off your computer."
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.
I just had a bootup of a laptop after what must have been a crash. Rather than fsck and check as under traditional init, it halted in systemd, because it had something to tell me. Which it didn't. So you log in to the single-user mode with a poor prompt (really, if you're asking me to log in, maybe you should *look* like a login). Then to see anything you need to run journalctl -xb. Nothing wrong with the disks as far as I could see. It seemed upset that there were a lot of logs in this boot. OK, so I reboot. And back to the same thing. You have to tell *it* to be OK that you've read the warnings. Then tell it to reboot. It being systemd.
So it's a regression, just extra layers of failure to get through when you already have an issue. All the same tools still have to run, but someone has to tie them together, and no one has. That's plebwork apparently.
Im sure RedHat engineers have no frigging clue what theyre doing, they should troll the slashdot boards more often for the grains of wisdom found here,.
With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged.
A lot of this criticism is coming from AC.
I tested your script on CentOS 7 and Fedora 21 a moment ago. Both logged your "Error that should not be thrown away" to both the journal and to the syslog messages file. Both detected that the service failed, and did not "throw away" its exit status.
And as another user pointed out, the old init system did not save stderr to the logs. systemd is an improvement in this aspect.
Services are easily manageable.
A bunch of us who actually manage systems tend to disagree.
Hundreds of DOS ini files, having to compile things instead of just modding a script, and not being able to step through a startup or shutdown process is not what we all consider easily manageable.
If it really were easily manageable, it would not have caught so much flak.
Sometimes you're the octopus, sometimes you're the girl.
No, it's NOT JUST A LAUNCHER. It's a logging daemon, a console input daemon, it's much, much more than just a launcher. So if for some reason (like power outage) your computer reboots, you can't just tail /var/log/* (or even specific logs, if you're familiar with your distro which most of us are). You have to use another computer to lookup some arcane command that's non-obvious (sorry, "tail /var/log/* IS obvious for anyone who has ever been a UNIX-world sysadmin), then you can proceed to fix the problem.
Now, personally, I'm willing to try it out on my laptop for awhile, and maybe, just maybe, I will consider deploying this in servers, in like 6 months after daily use by myself and my alternate. Otherwise we'll keep using 14.10 for now.
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.