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.
Unity is the metro of the linux world. It doesn't look like it, it just sucks like it.
"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).
I know how much Slashdot loves Systemd and Ubuntu. Pairing them together? Wonderful. Can't wait to see your responses!
> But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls
> decided they could reinvent the wheel better. Well so far the jury is still out on that.
You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it? NIH makes sense as a criticism in a few areas, but linux distros, largely run for free by hobbiests? They're imposing it on themselves for no good reason? Really?
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.
sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits
Fools rush in where Angels fear to tread.
The world is coming down.
At least the world of Free Software that was so close to my heart for the last 15+ years.
The simplicity of U--nix has reached the EOL. So has modularity.
Welcome, to new shores, the new U--s, full of mischievous monolithic blocks that accompany us from after PID 1 to shutdown and start our daemons, log us on, guide, lead, help, protect our systems and its users throughout the lifespan of their sessions. And beyond. From cradle to the grave - from boot to halt.
This is not my world any longer.
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."
So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?
When you cant win, ad hominem.
SystemD helps distro developers, there is no denying that. the denying is that it helps the systems themselves and the administrators who manage them.
When you cant win, ad hominem.
You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it?
Sure, there's a good reason. It makes things a lot easier for *them*.
Whether it makes things better or worse for everyone else remains to be seen.
No it doesn't remains to be seen, it's pristine clear that it's better for everyone else, as the "them" you're talking about are the only people affected by this change.
Which is exactly the reason why everyone else don't understand what the change is about, they were never aware of this part of the system, except when they were affected by a bug in it (and there are tons of bugs still present today in upstart, bandaids and the like).
It's striking to see that when Debian had sysvinit, Ubuntu made Upstart because sysvinit was such a pain. But the switch of Debian to systemd was enough of a step forward compared to managing Upstart alone, that Ubuntu decided to switch to systemd.
Gnome 2, MATE, XCFE, and maybe other desktops allow vertical toolbars too if you like it (not my case).
Alt-TAB window switching work equally well on all of them too.
I personally found both Gnome 3 and Unity catastrophic in term of productivity. I actually work with close to 40 virtual desktops and over 100 windows. I configured to switch around them using right CTRL+arrow keys, without any animation or effect. Blazing fast and simple.
It is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.
pint systemd to -1 as I did with my Debian 8. At least it will buy me two year more without systemd.
> 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.
slackware is kick ass for a long time and have the same 1 full time developer since ever.
but there is also a brigade of (part-time) hackers helping him behind the shadows
Higuita
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.
And anything but portable to other operating systems. We also have an example above of systemd ignoring output to stderr. Not cool.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
When you understand that Red Hat controls the Linux world, and what they do everyone will follow (with the exception of Slackware and Gentoo), you will understand.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
It worked.. except when it didn't. I should not have to hack my init scripts just because I have iSCSI or Clustered Fileystem mounts. Init was made in a time when the boot dependencies are more flat and don't do well at all when your setup requires network+daemon before the filesystem can be mounted.
Exactly! When you have several layers on top of your block devices, like RAID and LVM, it's even worse.
It was such a pain before, despite the LVM or multipath daemons, I was never sure the servers would reboot correctly, or the config freeze or corrupts itself.
Such a nightmare before systemd tackled the problems and sometimes the bugs in kernel or daemons, now it just works.
# 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.
I'm pretty sure they know what they're doing - but that doesn't mean they are acting in everyone's best interest either.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
There is a specific issue with setting static IP addresses on a CoreOS image that results in systemd deciding to execute both the DHCP and static IP address unit files in parallel - a clear race condition on startup.
What are you talking about? systemd doesn't set up network interfaces.
Do you mean that you can start both NetworkManager and the "network" service? Because in that case, both of them use the same configuration files for an interface (/etc/sysconfig/network-scripts/ifcfg-), so an interface can't have BOTH DHCP and static addresses. The network service also detects whether NetworkManager is handling an interface and will not configure it if so.
Finally, NetworkManager provides much better logging of its process than the network service does. If you want to debug the latter, you'd do it basically the same way you always have. "set -x" in the ifup scripts and look at the logs (which you have now with systemd, and did not in the past).
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.
I had been running Debian unstable for years, which contrary to its name was very stable (more stable than the stable releases of many other distros I'd tried, even). But once systemd was installed during an update, it was one broken thing after another.
Development branch of a distro, which is called unstable, sees breakage when switching the init system. A TOTAL SHOCKER.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
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.
Debian unstable is a misnomer. Before systemd was introduced, Debian unstable was very stable. Ubuntu's packages are based on the Debian unstable packages, as far as I know.
Before systemd, "stable" in the Debian lexicon referred to an extraordinarily high degree of stability, unmatched by other Linux distros. Even extreme stability appears to be "unstable" when compared to Debian's (former?) overachieving definition of "stable".
Somebody like yourself, who obviously has never used a truly stable Linux distro, probably couldn't understand this.
I ran Debian 15 years ago, you don't need to explain the fundamentals. The point stands that a development branch can break any time by definition, and the introduction of a new init system leading to boot failures here and there comes as part of your decision to run unstable. It's your fault if you upgrade without checking first, it's not systemd's fault. I've lost X or couldn't boot after an upgrade more than once.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Don't know about your job, years of running init rarely needed to debug or check why/if/when daemons aren't starting. on production systems. with users. with usb thingies. with eth failover.
Honestly, you fucking seriously mean to say THE FIRST PROCESS STARTED UPON BOOT NEEDS DEBUGGING and claim systemd is an improvement?!?!?
I can't tell if you are stupid or just a troll but I'll respond anyways. One of Systemds improvements is that it handles process (apache etc)reloads. One advantage to this, is that things are now restarted in the exact same environment (path, variables, CWD etc) as when the system is booting. The next advantage is that networking restart no longer needs to be run with nohup when done remotely, it just works now instead of dropping the interface and then dying.
This means that if say, a webdev or a junior admin makes a typo in a daemon and it fails to start you can now just use journalctl to see the output that previously went to console.
Less often(usually when I'm doing the initial setup), are things like iscsi, glusterfs etc that choked hard under the old init system and still need a bit (although easier) tweaking with systemd.
One Debian unstable breakage due to systemd is understandable.
Two Debian unstable breakages due to systemd is disgraceful.
A Debian unstable installation that will likely not boot properly after each update due to systemd, month after month, is unacceptable.
I use Debian since Bo, and I delivered this week to a customer my first embedded system based on Jessie with systemd. From this background, I say that Jessie is probably the best Debian release since his creation. For me, Jessie make SB2, WRT, Buildroot, OpenEmbedded, Yocto and all the others totally obsolete. Never was so happy to work building embedded systems than with Debian Jessie. Multiarch, systemd and MATE are exactly what I need.
I updated from system V init to systemd on the embedded system during the development and this was surprisingly smooth. Backward compatibility with system V init worked out of the box and the few minors issues was usual part of a first deployment or specific to my target.
Yeah, because I'm sure that the engineering costs are small in order to build a new system and win 2-3 years of "opaqueness" until everybody gets accustomed to systemd.
obligatory...