Ubuntu 15.04 Released, First Version To Feature systemd 494
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 added? (Score:3, Insightful)
Then it's simple.
"We changed everything."
No wonder it was short.
Re:SystemD added? (Score:5, Insightful)
Re: SystemD added? (Score:2, Insightful)
If I had mod points ...
PERHAPS someone could define what was broken so badly in init that the whole lot was replaced. I so dearly would like to know.
Re: SystemD added? (Score:5, Informative)
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.
Re: SystemD added? (Score:5, Interesting)
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.
Managability (Score:5, Insightful)
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.
Re:Managability (Score:4, Informative)
Thanks to systemd, every time I get a kernel update, I can look forwards to spending 4 hours trying to get the box to boot again. EVERY freaking time!
In Fedora 21, "single" boot mode doesn't even present a the filesystem you need to repair. I finally had to resort to a rescue CD. Not all my machines have CD drives attached anymore.
Re: SystemD added? (Score:5, Insightful)
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.
Re: SystemD added? (Score:4, Insightful)
No, because you would have already fixed the /etc/init.d/zfs file. And then you'd move on with your life, instead of googling "systemd dependancies editor" and going from there..
Comment removed (Score:5, Insightful)
Re: SystemD added? (Score:5, Insightful)
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.
Re: (Score:3)
You use Ubuntu on servers?
We do. So what? Ubuntu has a server distribution... it works great, is easy to maintain, and we use it for internal (behind firewall) use. And?
Re: (Score:3)
I do. The minimal standard Ubuntu Server release is simple, clean, CLI driven, and for all intents and purposes looks and acts no different than any other distribution that uses apt for package management.
Oh and getting things working is really well documented. Fixing complex problems is better left to the arch wiki, but for the basics of trying to do something on a server you're almost guaranteed to find an Ubuntu specific guide somewhere.
Re: (Score:3)
It reminds me of those 'That's now how this works. That's not how any of this works' commercials.
Re: (Score:3, Informative)
systemd, eh? (Score:5, Insightful)
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".
Re: (Score:2)
Re: (Score:2)
Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.
Er quite, though I was specifically referring to restarting PulseAudio, which takes a second not the entire computer. If the base underlying init process needs a restart, well, that's a different kettle of fish.
Re: (Score:3, Informative)
Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.
Er quite, though I was specifically referring to restarting PulseAudio, which takes a second not the entire computer. If the base underlying init process needs a restart, well, that's a different kettle of fish.
FWIW, the only time I restart systemd is to update the kernel, or I guess systemd itself (though the kernel changes more often and thus I can usually lump the latter in with the former). If you do live-patch your kernel, then you can do the same with systemd - it has a command to re-exec itself while preserving state.
I'm sure it isn't perfect, but it is as robust as anything else I've used on Linux. There are fairly few daemons that I've never seen need a restart sometime in the last 10 years.
Re: (Score:3)
There are fairly few daemons that I've never seen need a restart sometime in the last 10 years.
Pulse Audio. On one machine it's fine. On another it needs regular restarts.
Re: (Score:2)
Re: (Score:2)
As robust is not following the if it aint broke dont fix it model.
Re: (Score:3, Informative)
> overly complex to the point of being nearly undebuggable
Even worse is the fact that it ignores exit statuses and swallows stderr which makes it impossible to troubleshoot problems. While starting a process fails, systemd typicaly deletes all traces of why it happened.
Re:systemd, eh? (Score:5, Informative)
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.
Re:systemd, eh? (Score:4, Interesting)
I first used systemd on a complex custom embedded project that dynamically switch between multiple loads and it have saved me days of work compared to previous designs. Dependencies are managed the right way, and status+analysis tools are very good.
PulseAudio is unstable I agree (I juste deleted a ~1.5GB .xsessionerror filled with insanity from it, and it crash at least one a day), but not so systemd, even if journald need some more work to fix some minor issues.
Re:systemd, eh? (Score:5, Interesting)
Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.
Re:systemd, eh? (Score:5, Insightful)
The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage
Do you think Free Software was historically a democracy in which everyone voted and a team of developers slavishly set to work, granting their every wish?
No. Free Software systems were developed by people who needed the features that they wrote. Or wrote the features that they needed. Same thing. However you phrase it, the people who did the work made the decisions about what work was done.
And who is implementing systemd? The people doing the work. People who are willing to do the work to maintain a system which uses a different init will have a system with a different init. It's as simple as that. Slackware is such a system.
Re:systemd, eh? (Score:4, Insightful)
"Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage."
Truth.
Systemd/Fedora used "embrace & extend" tactic that Microsoft became so known for. Your average distribution has a suprisingly small amount of people whose job is to integrate packages into a cohesive whole and ship it out. Systemd/Fedora put them in a position where they either adopt everything they want, or fork & develop/maintain a growing number of packages -- all while not living up to their lipservice.
e.g., first it was udev, which is pretty important if you use removable media. Sure, you could build systemd and then only use the udev binary, but then that started getting harder. Then Poettering even started lobbying things like GIMP of all things to depend on systemd. Now, if you want to use Gnome3 -- or even ship it for your users -- it depends on logind, etc. It was pretty brutal and effective, all while they could go "you're getting this for free, you don't have to use it!"
Mark my AC words: we're heading for a corporate endgame where the GPL is run-around due to systemd. It's the goal of pushing kdbus into the kernel as well as sucking in everything from dns to a time server into systemd. Their corporate clients have the issue of shipping proprietary software & the LGPL on linux, but if it's just communicating with all the libraries as a service, well....
Re: (Score:2)
Ahhh Systemd and Ubuntu (Score:2, Funny)
I know how much Slashdot loves Systemd and Ubuntu. Pairing them together? Wonderful. Can't wait to see your responses!
So, then there we are. (Score:2)
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 - f
Contradictory summary? (Score:5, Insightful)
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.
SWEET (Score:2, Funny)
Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.
Re: (Score:2)
Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.
So you found vulnerabilities but don't even know how to exploit them ?
People talking about things they don't even understand...
Ubuntu: The End (Score:2)
Systemd? No thanks.
Ubuntu vs Mint (Score:5, Insightful)
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.
Re: (Score:3)
because mint is fresher? You should investigate a little about system optimisation. There are also specific distros for what you are doing if you are not that technically oriented.
To refresh your reading comprehension, what I said was, "Linux Mint was refreshing and met all my needs without problems."
That means that Mint was "pleasantly fresh and different". That means with after all the crap I put up with using Ubuntu Desktop(multiple versions) that when I tried Mint I was pleasantly surprised how good it works, and continue to be impressed to this day.
Regarding which distros to use, I did do quite a bit of research before trying Ubuntu Desktop, and I also tried about 3-4 othe
Phone Home (Score:2)
Re: (Score:2)
Re: (Score:2, Funny)
Unity is the metro of the linux world. It doesn't look like it, it just sucks like it.
Re: (Score:3, Interesting)
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).
Re:Unity next (Score:5, Insightful)
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.
Re:Unity next (Score:4, Informative)
Debian Jessie with MATE is very good too. Should be released tomorrow AFAIK.
Re: (Score:3)
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
Re: (Score:2)
I remember how Ubuntu 10.04 came out, I installed it from the network (no need for a DVD or USB drive!) and I thought that great, the linux desktop is done. Stable, great looking. Then just a year later, it's back to a mess, great user fragmentation among distros and DEs, and then in a continual state of transition (and I need to buy USB drives to install linux mint).
Ubuntu MATE possibly is a very good idea, but it's now an also-ran. It feels to me sort of like it's downstread from Mint, too. Too bad that i
Re:Unity next (Score:4, Interesting)
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.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
Unity changes it around so you go to the side (a good place to put things on a 16:9 monitor)
It's a good place on a 16:9 monitor. Not so good if you have a 4:3 monitor, or multiple monitors or simply want an option to change it to the bottom, right or some other behaviour.
Re:Unity next (Score:5, Insightful)
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?
Re:Unity next (Score:5, Funny)
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.
Re: (Score:2)
for small workloads (eg: home users), unity is good. Mate is also good ... Their major problem is that it still have that "not free enough!" or "it uses C++!!" shadow, that scared many to start gnome. Since then many things changed, but Redhat/fedora still run from it like hell and ubuntu always hide kubuntu from most people.
for high workloads, with many windows open, openbox, fluxbox, awesome, dwm, ratpoison, etc are better
KDE is not bad too, as it is very flexible and lighter today than gnome
Gnome shell,
Re:systemd rules!!! (Score:5, Insightful)
"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.
Re:systemd rules!!! (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
> 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.
Re:systemd rules!!! (Score:5, Informative)
> 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.
Re:systemd rules!!! (Score:4, Insightful)
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.
Re:systemd rules!!! (Score:5, Informative)
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.
Re: (Score:3)
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?!?!?
Re: (Score:3)
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
Re:systemd rules!!! (Score:5, Insightful)
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.
Re: (Score:3)
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 pro
Re: (Score:3, Informative)
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 usele
Re:systemd rules!!! (Score:5, Informative)
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.
Cannot reproduce your test case (Score:5, Informative)
# 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.
Re: (Score:3, Interesting)
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 indicati
Re:systemd rules!!! (Score:5, Interesting)
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.
Re:systemd rules!!! (Score:4, Interesting)
Because stderr isn't being hidden under systemd. It's logged to both the journal and the syslog messages file.
Re: systemd rules!!! (Score:2, Insightful)
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
Re: (Score:2, Insightful)
systemd service files are far less complex that the stack of init scripts need on top of system V init. The status and reporting is incomparably better than anything before it.
Re: (Score:3)
Re: systemd rules!!! (Score:5, Informative)
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.
Re: (Score:3)
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?
Re: (Score:2)
systemd is a bad joke (Score:5, Insightful)
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!
Re: (Score:2)
So Linux is adopting the Microsoft way of doing things (Vista, W8 and the butchered Start menu since W7)?
Re: (Score:3)
Re: (Score:3, Insightful)
Re: (Score:3)
Re: (Score:2, Troll)
As someone who, apart from continually getting the verb and daemon name backward, actually likes systemd, I'd like to know what issues you are talking about. So far the only issues I've had, has been having to learn some new commands.
Forewarned is forearmed 'n all that.
Re:systemd is a bad joke (Score:4, Interesting)
You can't just leave things alone, because computers have also changed. Today we do not work on mainframes or desktop computers, but increasingly on laptops and mobile phones, which constantly change state, in terms of network connections, devices plugged in, location, hibernation.
I think there is consensus that these things did not work well on the old init system, although band-aids were found. I remember that changing the hostname stopped X from working, which can occur when DHCP gives you a new hostname. That is 80s design for you. Or changing the time messes up the logfiles.
Now you can choose which modern init system you want, and there are a couple out there: OpenRC, upstart and systemd are the most well-known ones.
OpenRC is the familiar runlevel based approach, which runs scripts which may or may not succeed.
Upstart is a triggering framework, that takes pre-defined actions (but does not work with goals). That means you have to write tasks for how to get from A to B with your system.
systemd is a dependency resolution program, that knows what to activate next to get to a certain state (goal). It handles services, mount points and network connections in the same framework. It is essentially an overseer of a services tree.
There are some upsides to systemd, besides parallelizing the tasks of a dependency tree to reach a goal. One is for every process it is known which service launched it (there are some Linux-specifics that allow marking those processes). Also, each service can be assigned resources (memory, number of processes), which it can not exceed (again, modern Linux supports that). And, obviously, you are not limited to a set number of runlevels.
Yes, systemd is annoying, because it is a new thing to learn. And it is annoying, because the maintainers are inconsiderate. But in the end, it is just a program to start other programs, with one particular way to do it. I don't get what the big deal is. If it is feature bloat -- Linux also has a lot of features, so does VLC -- there we consider them a good thing. Technically, the dependency resolution approach of systemd seems like a good thing (as in progress for Linux) to me.
Re:systemd is a bad joke (Score:5, Insightful)
I think the big deal is how decisions are made: In the past, somebody would write a new software and people who liked or needed it would start to migrate to it. Then later it may become the default, but other software would still continue to work and be supported for a long time. Nowadays, a decision is made somewhere and changes are pushed to users who do not want it, while support for alternatives is dropped quickly. So in the end, I think it is a question of software freedom in a very real and practical sense.
Re: (Score:2)
> 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?
Re: (Score:2)
Never underestimate the power of the herd mentality.
"but linux distros, largely run for free by hobbiests?"
Its not 1995 anymore.
Re:Upstart or Systemd? (Score:5, Funny)
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,.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:3)
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 bec
Re: (Score:3)
SystemD helps distro developers, there is no denying that. the denying is that it helps the systems themselves and the administrators who manage them.
Re: (Score:3, Informative)
Re:Upstart or Systemd? (Score:4, Insightful)
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.
Re: (Score:3)
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... [xkcd.com]
Re: (Score:3)
Re: (Score:2)
Are you certain that Debian fit your definition ?
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
Oh right. Because the systemd config is sooo simple in a situation like that.
Re: (Score:3)
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.
Re: (Score:2)
"And your vision of systemd is wrong by the way : educate yourself please."
How about you tell me then. Apparently you're such an uber admin that surely it'll be no problem to list the advantages of systemd compared to init. Right?
Re: (Score:3)