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.
Then it's simple.
"We changed everything."
No wonder it was short.
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.
"We've adopted it on an increasingly large scale and we are seeing the rewards already."
List them. And be specific - no vague handwaving waffle please.
Agree but i've had problems with Mint for a while, and the official forums for it are dead; you're much more likely to get help on AskUbuntu or UbuntuForums, so I've gone back to Ubuntu then upgraded the ui to xfce. Problem solved! (I tried briefly but unity is still a mixture of awful and buggy).
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.
I've been using Unity for a few years and I like it. Typically I might have several browser windows, several terminals, and other windows like WireShark open. In the older UI these would have all been accessible from the bottom bar, and there might be twenty or so tabs there. Unity changes it around so you go to the side (a good place to put things on a 16:9 monitor) and select the browser, terminal, or another icon. With the muscle memory in place it has worked very well. Alt-tab also works as you might expect. I also have Mac laptops, and it's not especially annoying to go from one UI to the other.
In the last year and a half I have tried several different Linux desktops to run on a small form factor Dell pc connected to my TV via HDMI.
I settled on Ubuntu for a variety of reasons and was reasonably pleased with it.
However, after a few weeks things started to go wrong.
Errors, lockups and other things cropped up that started to really get old.
I read forum posts, blogs, "kb" articles to fix the various issues I had with Ubuntu.
Eventually I wiped it and reloaded it, and the same sorts of problems came back.
I was ready to install Windows when I read someone mention Linux Mint.
So I gave that a try.
Like a cool spring breeze on a warm afternoon, Linux Mint was refreshing and met all my needs without problems.
To this day I wonder why Mint works so well when Ubuntu Desktop was such a POS.
We play the game with the bravery of being out of range
Debian Jessie with MATE is very good too. Should be released tomorrow AFAIK.
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 is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.
> 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.
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.
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 think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console. systemd hides the information you need. Instead of taking thirty seconds to fix this problem, it took us most of a day and required using strace to see the stderr output that systemd hides.
Even worse is trying to troubleshoot SELinux-related problems. SELinux is very sophisticated so anything that hides stderr or deletes syslog messages makes life very difficult.
I've been using Unity for a few years and I like it...
Me, too. And my wife, my kids, my father, my mother in law. But most people who enjoy using Ubuntu aren't the kind of people who post on /. But power users who need advanced features not offered by Unity are presumably also sufficiently sophisticated, knowledgeable and competent to effortlessly install an alternative desktop.
Problem solved. Simpletons like me and my family can use the dumbed-down nursery-school, colour-by-numbers default desktop interface. Clever, technical people can type a few commands starting with 'sudo apt-get install'. I don't get why everyone isn't happy?
With the muscle memory in place it has worked very well.
The same can be said about masturbation. Doesn't mean it's better than actual sex w/someone else.
It must have been something you assimilated. . . .
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,.
And the RedHat decision was motivated by...?
Money
The more opaque and difficult you make the system, the more likely people will pay for support.
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.
Also, look at the journal using "journalctl -u named" to see that the output doesn't log the expected error "named: unknown option '--'". It is not logged
I don't know what to tell you, AC. You're wrong. I test every "example" of systemd problems that ACs post in this thread and they're all wrong. systemd logs daemon stderr to both the journal and to the syslog messages file.
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.
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.
Because stderr isn't being hidden under systemd. It's logged to both the journal and the syslog messages file.
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.
Oh my, I want to step through 3000 steps manually before I get to my program of interest, and I also want to see 1000 lines of spurious crap for things I don't care about.
Besides, systemd is not based on Unix, ... that's why portability of systemd to other Unix was thrown away.
That sound you hear is a collective sigh of relief mingled with drives spinning up as new downloads of various Unix flavors start in earnest.
The cesspool just got a check and balance.