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.
"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.
I don't see how the summary's, 'don't fix what isn't broken,' statement applies in this case.
Do not look into laser with remaining eye.
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.
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
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."
> 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.
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.
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,.
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.
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.
A recent of example I had that made me dislike systemd was a prototype RHEL7 system here that has ZFS-on-Linux support installed on it.
When you boot it up, there's around a 50/50 chance whether the ZFS filesystems will be mounted after boot. This is an inconsistency that, as a long time sysadmin, REALLY BOTHERS ME.
Yes, I realize the root cause. ZFS has some dependency that is not starting before it. The dependency has to be declared in the appropriate service. However, with systemd we introduce the concept of "just because it came up correctly on this boot doesn't mean it will on the next one."
And that is supremely frustrating. What if it weren't 50/50? What if the likelyhood it didn't come up was 1/100? Suddenly a routine reboot becomes a debugging mission, and I reboot again and it works. "Eh, must have been a transient problem." No it wasn't.
With classic init you were fairly sure that the system's state was the same on every boot. Now it's a gamble. Good luck with that! This is why we're sticking with RHEL6 for the moment on production systems.
Uhhhh...yeah dude? The post he is referring to used "compartmentalized", "intrinsic" and "homogeneous" in less than 3 sentences....normal folks and IT guys? yeah they don't talk like that. So the poster is either 1.- A shill, or 2.- Works in PR or marketing, because those guys DO talk like that.
Frankly I was shocked he didn't roll out "synergy" but I think they wised onto it thanks to Dilbert ragging on it so many times.
ACs don't waste your time replying, your posts are never seen by me.
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.