Ask Slashdot: Can You Say Something Nice About Systemd? 928
ewhac writes: "I'm probably going to deeply deeply regret this, but every time a story appears here mentioning systemd, a 700-comment thread of back-and-forth bickering breaks out which is about as informative as an old Bud Light commercial, and I don't really learn anything new about the subject. My gut reaction to systemd is (currently) a negative one, and it's very easy to find screeds decrying systemd on the net. However, said screeds haven't been enough to prevent its adoption by several distros, which leads me to suspect that maybe there's something worthwhile there that I haven't discovered yet. So I thought it might be instructive to turn the question around and ask the membership about what makes systemd good. However, before you stab at the "Post" button, there are some rules...
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
Bias Disclosure: I currently dislike systemd because — without diving very deeply into the documentation, mind — it looks and feels like a poorly-described, gigantic mess I know nothing about that seeks to replace other poorly-described, smaller messes which I know a little bit about. So you will be arguing in that environment."
Nice Things About systemd Rules:
- Post each new Nice Thing as a new post, not as a reply to another post. This will let visitors skim the base level of comments for things that interest them, rather than have to dive through a fractally expanding tree of comments looking for things to support/oppose. It will also make it easier to follow the next rule:
- Avoid duplication; read the entire base-level of comments before adding a new Nice Thing. Someone may already have mentioned your Nice Thing. Add your support/opposition to that Nice Thing there, rather than as a new post.
- Only one concrete Nice Thing about systemd per base-level post. Keep the post focused on a single Nice Thing systemd does. If you know of multiple distinct things, write multiple distinct posts.
- Describe the Nice Thing in some detail. Don't assume, for example, that merely saying "Supports Linux cgroups" will be immediately persuasive.
- Describe how the Nice Thing is better than existing, less controversial solutions. systemd is allegedly better at some things than sysvinit or upstart or inetd. Why? Why is the Nice Thing possible in systemd, and impossible (or extremely difficult) with anything else? (In some cases, the Nice Thing will be a completely new thing that's never existed before; describe why it's good thing.)
We will assume out of the gate that systemd boots your system faster than ${SOMETHING_ELSE}, so no points for bringing that up. Bonus points are awarded for:
- Personal Experience. "I actually did this," counts for way more than, "The docs claim you can do this."
- Working Examples. Corollary to the above — if you did a Nice Thing with systemd, consider also posting the code/script/service file you wrote to accomplish it.
- Links to Supporting Documentation. If you leveraged a Nice Thing, furnish a link to the docs you used that describe the Nice Thing and its usage.
What Does Systemd Mean to Me? (Score:5, Funny)
By
eldavojohn
Systemd has a nice ring to it. The way the syllables roll off my tongue pleases me greatly. It could be the title of a great anime series. It could even be the lost name of an ancient forgotten god-king. It might even be the name I give my first born. It sounds much more authoritative and genuine than sysvinit or upstart or inetd. For instance from my non-technical fourth grade perspective this is what I interpret the others to mean:
Contrary to your base assumptions, systemd does not actually boot faster on my Pentium II (Intel inside) system. I just like the way it sounds.
Re:What Does Systemd Mean to Me? (Score:5, Interesting)
We've had problems a few times with systemd (usually the next boot after an upgrade to a package). Without exception, the failed boot occured with next-to-no meaningful error on the console and was more difficult to debug than if it had been using sysvinit. I personally, as a sysadmin for ~16 years, don't see a problem with sysvinit that justifies tearing it out of Linux for a more complicated, more opaque replacement.
Re: (Score:3)
ok - comments can be closed I think.
There should be no more to say here.
It freakin' works fine (Score:5, Insightful)
I've done migrational upgrades to System-d with Arch Linux with zero problems in addition to using it with new installations. It works fine, and I'm still really confused about the jihad-level hatred it seems to engender in some people.
Re:It freakin' works fine (Score:5, Insightful)
Remember how awesome pulseaudio is? Well what if we made your ENTIRE SYSTEM that awesome?
Re:It freakin' works fine (Score:5, Insightful)
Pulseaudio works fine.
People think it sucks; the reality is that the implementation in Lolbuntu was done poorly, giving the non-competent people a bad taste of it.
I used it in its first versions, and it handled my 5.1 setup perfectly, switched to headphones when I plugged them. And it had per-application volume working out of the box.
It's one of the first things I install when I install Debian.
Re:It freakin' works fine (Score:5, Funny)
I used it in its first versions, and it handled my 5.1 setup perfectly, switched to headphones when I plugged them. And it had per-application volume working out of the box.
AKA the "I like PulseAudio because I coincidentally owned the hardware it actually supported well" comment.
Re:It freakin' works fine (Score:5, Funny)
Hey, it's not HIS fault your cow wasn't spherical enough!
Re: (Score:3)
Re:It freakin' works fine (Score:4, Interesting)
Remember how awesome pulseaudio is? Well what if we made your ENTIRE SYSTEM that awesome?
Oh I could only dream. Imagine that, a system which can cope with plug and play and access to multiple pieces of hardware at the same time. A system which can seemlessly switch outputs as hardware becomes available. My god that would be an amazing system.
Actually you've demonstrated the parent's point very well. Pulseaudio like systemd solves very real problems. It had teething issues and now seems to work rather well. If my experience with systemd will be anything like it is with Pulseaudio then I say bring it on.
Re: (Score:3)
what pulsed solves is not very important problems, for me at least.
But it introduces strange problems, besides eating CPU-cycles and RAM.
For example, I resently spent some time debugging why icedove occasinally froze. It turned out that it was trying to play a sound, but that went wrong because the user starting icedove was not the same as the user starting the desktop even though both were in the audio group.
It should be possible to make pulse work in system mode, but I could not get it to work well. But d
Re: (Score:3)
The problem stems from the fact that they solve very hard problems. Audio IS hard - it's not just putting a stream to a card and having a beep come out from a speaker anymore - nowadays audio is FAR more complex. Most computers now have various ways to get audio in and out - a hardware ADC/DAC (sound card), Bluetooth, HDMI, digital (S/PDIF, T
Re:It freakin' works fine (Score:5, Interesting)
Are you trying to imply that all the hatred I've heard about pulseaudio was also unjustified?
Only if you have a setup like Potterings, since he rewrote the pulseaudio configuration to work on his computer and just deleted features he wasn't using to "keep it easy".
Sort of like how if you're using systemd in an NFS world you're going to have a bad day, since he still hasn't made their dependency resolution work correctly with networked filesystems. Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc, I suppose we'll need the kernel rewritten to support a systemd-mount program to solve this problem, which will of course be incompatible with standard mount.
Re: (Score:3)
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies. What's the issue that prevents that working?
Re:It freakin' works fine (Score:5, Interesting)
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies.
Yes, exactly. So, by developing a clear understanding of systemd syntax and dependency specification, you should be able to solve the dependency problem that rc/sysvinit solved fifteen years ago by specifying that dependent processes start after their requirements.
This is actually a silly example. If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out. You can do it manually, in your head, and your brain can process what's going to happen. Systemd introduces a massive complication by allowing init processes to happen in parallel. So, now you've got this horrible optimization to do, where you separate all of the separate init processes into mutually independent sequences that start in parallel. So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?
My point is that the dependency issue is really something that systemd introduces, and the benefit of its automatic dependency resolution is only relevant in the context of systemd. If it's really important to you that your computer be able to start multiple daemons in parallel, rather than wait the 5 seconds it takes to start bind before starting apache or samba or whatever, then systemd does that and solves the problems it introduces. If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.
Re:It freakin' works fine (Score:5, Insightful)
Nonsense, it is a load of crap. He even wants to throw away parallel startup. Why? "If all of the start-up processes are loaded sequentially, then order is really not a hard thing to sort out." Well, shucks Wilbur, this is like the guy that is against fuel injection because carburetors are easier to understand. Nevermind that fuel injection is better in every way, and that the technology is easy to work on for properly trained mechanics.
So, your brain can tell that you should start network file systems only after you've started the network, but how about the audio driver? Can you start named in one process while starting apache in another?
This is actually so much easier than you imagine... if understanding the dependencies is too hard for you, don't re-order them. You should not need to, it is not a normal part of system administration or software development. Let the good people who develop your distro worry about these hard parts. Trust that they hire or appoint people smart enough to understand their job, and get on with your life.
There is no new dependency "issue," there are just new capabilities.
If you'd rather understand what happens as your system starts up and not trust someone else's optimization, then systemd is not for you.
The bad news is, since a person with this concern doesn't understand how really any of the boot process and software works, distros are not for you and you should write your own because that is the only way you're going to understand what it does. The argument really falls on its face. If people understand what their computer is doing at that level, they can understand parallel startup. Sorry, they can.
Re: (Score:3)
This is news to me. My main PC (debian jessie) has four cifs mounts on startup and they all come up with no trouble. The only systemd issue I've had so far was a minute and a half hang on startup that I couldn't spot but that was fixed by the latest debian update making the startup process actually tell me what it was doing. Turns out I had a swap entry in /etc/fstab from an old drive I removed ages ago and systemd was giving it a full 90 seconds in case it was slow to initialize rather than not there.
Re:It freakin' works fine (Score:5, Funny)
I'm looking forward to the next follow up:
Ask Slashdot - Can you say something nice about Florian Mueller?
or no even better:
Ask Slashdot - Can you say something nice about Slashdot Beta?
Re: (Score:3)
Re:It freakin' works fine (Score:5, Insightful)
I've done migrational upgrades to System-d with Arch Linux with zero problems in addition to using it with new installations. It works fine, and I'm still really confused about the jihad-level hatred it seems to engender in some people.
But "works fine" isn't really a Nice Thing as defined in TFS. I mean for very large values of "worked fine", so did the old scripts. It's not like my computers only became usable this year.
"works fine" is the minimum acceptable level for an init system.
Re:It freakin' works fine (Score:4, Insightful)
Think back to the epic holy wars of the past. Emacs vs. Vi. Big vs. Little Endian. Motorola vs. Intel. Amiga vs. Atari ST. ASCII vs. EDBIC.
Some people go to war over which part of their dick they are supposed to cut off. Some people go to war over a text editor. It's human nature.
Re: (Score:3)
Re: (Score:3)
Legacy? 5 years ago we had to interface with a bank who used XML with EBCDIC fields.
Re: It freakin' works fine (Score:5, Insightful)
I have used Linux for 15 years without any problems.
I've used Linux since the kernel versions started with a 0.
If you haven't had any problems you aren't trying hard enough.
Re: It freakin' works fine (Score:4, Informative)
I have used Linux for 15 years without any problems.
Think again. For example, do you remember in the past 15 years you experiencing any of the following while using Linux?
- the desktop is tearing (vsync problem)
- suspend or hibernate is not working properly
- you get a blank screen when X.org starts
- making manual modifications to the system as a workaround for a bug
- a power management issue has bitten you, such as the system consuming too much power, overheating, or fan spinning constantly
I am not making comparison to Windows or Mac here, because they have their similar bag of problems. Your claim was about using Linux without any problems.
Betteridge's law of headlines (Score:4, Informative)
Betteridge's law of headlines [wikipedia.org] is an adage that states: "Any headline which ends in a question mark can be answered by the word no.
Is this the right headline to apply it on?
Re: (Score:3)
Except that "Can you say something nice about X?" is a defensive question.
Out-of-the-box babysitting of processes (Score:5, Informative)
I like that in the future when the integration is more complete, I'll be able to install a database or a webserver and then once in a full moon when a cosmic ray hits the process and kills it, systemd will just restart it.
Yes, you can do that with other tools too once you've learnt your lesson (many years ago I had 1.5 year uptime with Apache and then it suddenly crashed) and I am using one of those at the moment. What I like is that this will just work out of the box for newbies and veterans alike with no clunky configuration/interfacing.
Re:Out-of-the-box babysitting of processes (Score:5, Insightful)
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.
Secondly, there may a *reason* the process goes down, and having it down may be a good thing. If someone's trying to fuzz our httpd process for exploitation, then it happily restarting will open up a wider attack window.
Autopilots on production servers seem like a bad idea to me.
Re:Out-of-the-box babysitting of processes (Score:5, Insightful)
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
I have the opposite view. If something goes down:
1) I want to know about it. I want some monitoring system to send me an alert of some description.
2) I want it set up in a way that it won't clobber it's own log files. Preservation of the reason something failed is key.
3) I want it to automatically restart if possible. I say if possible because I want to avoid a re-start loop but if something goes down and comes back up then the end user is happy as uptime is maximised and providing criteria 1 and 2 are met I'm no worse off as an admin. Believe it or not random crashes may sometimes happen and may have nothing to do with the config or the system itself. I may be caused by some edge case that was hit by a user, and in those cases I am unlikely to find the problem quickly and in the interest of not limiting user access would be inclined to get the system up and running as quickly as possible and then sort through the log history into what the actual problem was afterwards anyway.
Mixed feelings (Score:5, Insightful)
Re: (Score:3)
Maybe I'm unique in this regard, but as an admin, if something goes down on one of my servers, I want it to stay down until I intervene.
The problem here is that in complex production environments, servers are not atomic units. Obviously, if the network is down, apache cannot run, but just because the LDAP server is out of commission, that doesn't mean that webapps that don't use LDAP cannot continue to run.
That's the potential of systemd. To ensure that a process that cannot operate except when other processes that is depends on are OK.
'
Firstly, if I'm properly monitoring the process, then I'll be alerted and can investigate.
Secondly, there
Re:Out-of-the-box babysitting of processes (Score:4, Interesting)
A long time ago I used to do that with inittab. And then suddenly that was wrong, we weren't supposed to use inittab anymore, everything was supposed to bin in an init script.
Whatever
Re:Reliable servers don't just crash (Score:5, Insightful)
Reliable servers don't just crash.
Obviously you haven't learned your lesson yet. Hardware failures happen.
Re:Thanks for making my point (Score:5, Insightful)
In which case a nanny process restart is useless. Thanks for making my point, idiot.
Many hardware failures are transient, and a process restart is a very effective fix, at least in the short term. In the longer term, you'd better have monitoring in place so you know that the restarts are happening and can decide when to fix the hardware.
In addition, many process crashes are caused not by hardware failures, but by obscure software defects, and a process restart is not only effective at getting the production system back online, but arguably is a complete solution to the problem if the defect is sufficiently obscure that it's very rarely triggered, and hence not worth the large amount of effort required to identify and fix it.
Re: (Score:3)
Re: (Score:3)
Also, not coincidentally, quietly allowing hardware problems to persist until data structures and the filesystem to be corrupted before anybody notices.
Hence the importance of monitoring so that the failure is not quiet, as I already pointed out. Please try reading and fully understanding posts before responding.
Re:Thanks for making my point (Score:4, Interesting)
Not to mention crashes caused by rare, hard-to-reproduce race conditions.
Indeed. That is one sub-category of the obscure software defects I mentioned. It's probably the best example, actually.
It's interesting to describe the approach used by many systems at Google (where I work; I'm now in Android but used to work on Google servers): a common pattern at Google is to crash immediately upon detection of any error. This is actually just a logical extrapolation from Google's long-used approach of building reliable systems on top of cheap, unreliable, commodity hardware, applying the same notion to individual software components. System designs assume that anything can fail at any time, and are built to recover gracefully, possibly with some degradation. So there is extensive infrastructure to fail a request over to to another process instance, and to automatically restart any failed processes. And of course there is extensive and detailed monitoring, with lots of statistical analysis of failure modes plus charting of everything to enable patterns to be recognized and various forms of alerting, ranging from automated bug filings, to e-mails, to pages delivered to on-call engineers.
Given that approach to fault tolerance, it's often very reasonable, at least for non-Java processes, to simply abort/crash whenever anything goes wrong. Restarts are automated and fast (for non-Java processes; JVMs are a bit slower to start) and monitoring and alerting take care of letting people know what happened and how often. This includes both hardware and software-related failures. Monitoring also pays special attention to processes that fail repeatedly (called "flapping") upon restart and generates high-priority alerts. The restart infrastructure will also slow and even stop the restarts of flapping processes.
Anyone who's used the googletest [google.com] unit test framework for C++ may have wondered about the extensive support for and documentation of so-called "death tests", which allow you to verify that your code crashes when it's supposed to, and in the right way. This is a consequence of this particular approach to fault tolerance; if crashing is part of your reliability plan, you need to test that your code crashes when and how it's supposed to.
None of this has anything to do with systemd, of course. The fact that a strategy is effective in Google's environment is utterly meaningless in single-server contexts. In this case, though, auto-restart plus monitoring and flapping control seems like something that could usefully work in many contexts, perhaps even as the default.
Re:Thanks for making my point (Score:5, Interesting)
In which case a nanny process restart is useless. Thanks for making my point, idiot.
Your logic is flawed. Random bit flips sometimes happen [oracle.com]. They don't necessarily take down the whole machine.
Re: (Score:3)
I worked on space rated instruments at NASA Goddard for a while, and talked to a very old dude who claims to have seen this happen once in his very long career.
Re:Thanks for making my point (Score:4, Informative)
It happens about 40 times a day on you average PC
No, it doesn't. I operate lots of machines with ECC RAM. I've seen ECC correction. Bits flip, but nowhere near that frequently. It's very rare.
Re: (Score:3)
It's not like the journal format is some state secret. It's documented and there are already several journal parsers to choose from.
Re: (Score:3)
At least with journald you can have logging done just binary, just text or both types simultaneousl
False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.
Of course you can have text only log files. Just tell journald not to make any journal files, and forward log messages to rsyslog. It is trivial to do.
Btw, did you know that rsyslog was started because of the inherent limitations of flat text files. These limitations is why all Unix/Linux Enteprise central logging solutions involve some kind of database (Splunk, rsyslog with db-driver modules etc).
Really, systemd's logging solution is seriously cool. It is worth a serious try out.
Re:Reliable servers don't just crash (Score:5, Insightful)
Reliable servers don't just crash.
Thanks for reminding me .. I always forget to add this to my source code:
#define RELIABLE
Nice Thing: systemctl status shows you log entries (Score:5, Informative)
If you have a service called 'foo', then 'systemctl status foo' not only shows you whether the service is running, it also shows you the last 10 log entries created by that service. This is great when the service failed; usually the error message will be right there.
How does it do this? Well, because all processes created by the service are in the same cgroup, all of the log messages (and even anything they print to stdout, which would have been lost otherwise) can easily be tagged with the service name (and a bunch of other metadata). You can use journalctl to query the journal for the logs from a specific service, and systemctl status does this for you.
Re:Nice Thing: systemctl status shows you log entr (Score:5, Insightful)
My problem with things like systemd is not that they have nice features - lots of things have nice features. Windows' Shadow Copies is a lovely feature that's a lot easier to configure that some alternative equivalents, etc.
It's that they put those nice features into some new paradigm of configuration when you could have just added them to the existing system.
Re: (Score:3)
If you think you can add this nice thing to syslog, then please do. Quite a lot of people will sing your praises, in fact.
Re: (Score:3)
No, that's not what I mean. You've removed the new "useful" features that I'm okay with - and might want - but in doing so you've told me to replace everything I have with systemd.
Much more useful to me would be to get that listing, with those log tails, on a sysVinit. And that is far from impossible.
What we have here is bundling issues. Want the nice feature that does something quite simple? Then change everything you have to our system.
That's systemd's problem (and your response is their attitude) in
Excellent Tower of Hanoi solver (Score:5, Interesting)
Using the information gleaned from this year old bug [redhat.com] I was able to create a Tower of Hanoi solver using the dependency resolver's attempts to determine whether a NFS filesystem should be mounted after the network comes up or not. Every attempt to start Apache (which depended on the filesystem) represents moving a disc to the middle tower.
How about "I couldn't care less."? (Score:3, Insightful)
Seriously, I've been a Linux Guy since the 90ies and I honestly couldn't care less.
Anything I know about init is about runlevels - and those are a really neat thing. I mean really cool. You can fiddle with those using mc (Midnight Commander) and debian has a stack of 4-6 of those preconfigged and set up by default - last time I checked, some 7 years ago or something anyway.
Point is, my grandma can set up a runlevel that ex- or includes the LAMP stack in it's 'launch', 'init' or whatever-it's-called sequence and I can set my box to it by typing "init [simple Int here]" for my box to go there.
Again, that is pretty neat and cool and the best working solution I've run into so far.
Way better than anything in the Windos world, that's for sure.
If this "systemd" thing - whatever that is - doesn't break this or offers a neater improvement on that runlevel stuff or a way better concept that's worthwhile moving into, perhaps like the SVN vs. Git thing in which Git comes out on top IMHO - without requiring some bullshit GUI tool to be usable, that's all very fine and dandy with me.
If, on the other hand, you're going to push this new fad and hurt me wile doing so, I'm coming for you some time in the future. With a baseball club and my mafia friends. Other than fucking around with one of the best filemanagers ever - Konqueror - and replacing it with an inferior dolphin - this isn't some GUI toy you should fiddle with. This is Linux at a level where it's actually *the* industry standard. As in 'no other even comes close to this level of reliability and quality". Fucking that up would be a really stupid idea.
Otherwise I really positively couldn't care less - and that's how it should be, no? Except for, maybe, if I were a System Developer or Distro Release Manager or something.
My 2 cents.
Wrong. (Score:3)
You are NO Linux guy! A Linux guy cares about all things Linux, however slightly.
Wrong. A Linux guy cares more about Linux than any other OS and is one who's judgement perhaps has a little weight.
Like, if he's been programming since '85 or something like that and has been using *nix during the times when the only usable editor on it was Emacs or Vi.
You may not believe it, but I, and quite a few others who do computing for a living, actually have a life outside of computers and fiddling with init-scripts and
systemd needs to stay optional (Score:5, Insightful)
'systemd' needs to stay optional, and I mean that explicitly. optional. Not "default", and not "optional, in the sense that you then have to do the maintainer's job for them because they are too lazy to consider people not using systemd, because systemd is the default, and the maintainer does not want to consider the people that dont want systemd, regardless of the reasons or circumstances." kind of way.
Systemd is potentially useful for only a subset of the linux ecosystem, and forcing this kind of change is a bad thing.
Please allow me to explain why:
Systemd seeks to be a "Be all, end all solution to system initialization", which ultimately means that it will itself try to cover every possible thing that its maintainers believe needs to or should happen during system init. That in and of itself means that it will be large and cumbersome; exactly the things that embedded linux should avoid, where ultra-minimalism is king. (We are talking systems that have just a few dozen megabytes of memory, and just a few hundred megahertz of processor power at the most. Having all that gobbled up by the init system as soon as power is applied is not going to win you any trophies, and boldly asserting that embedded devices need to obey a desktop paradigm is throwing the baby out with the bathwater.)
This is especially true with "reference distributions", like debian. Debian "console only" deployments with tools like debootstrap are reasonably common with embedded devices, as are deployments that make use of chroots for specific sandboxed services. A chroot does not need a full blown init like systemd. It is best served with a simple init script. Building a distro with the intention of killing simple init, and replacing it with a monolithic solution like systemd will make service daemons much more difficult to control in this way, and will actually rob core functionality away from the distro that goes that route--- exclusively in favor of desktop flavored deployments.
Linux is more than desktops.
Linux is routers.
Linux is home automation systems.
Linux is servers performing specialized functions.
Linux is so much more.
Please be more considerate about trying to force systemd into debian. Optional is OK. Optional like "gnome vs kde vs xfce vs $ManagerHere". Not "optional" like "unity on ubuntu". Debian is a reference distro, upon which many other distros are based. It has already found its niche in the linux ecosystem. Please dont try to reinvent it.
Re: (Score:3)
I think systemd is excellent for servers, I think the wide adoption by PaaS vendors proves this. I also happen to think process management is good for most embedded systems. Because they often have less support, both human and other infrastructure being able to do internal process management is a plus. So I disagree strongly that systemd is about desktop, that's a myth.
That being said though I agree that systemd is a bad choice for low memory embedded systems. But frankly I think Debian is mostly a bad
Re:systemd needs to stay optional (Score:4, Insightful)
debootstrap. All you need is a disk that is mounted, and access to a repository.
https://wiki.debian.org/Deboot... [debian.org]
The packages it installs are just the core debian console-only base system. Nothing super fancy. It can consume upwards of 300mb of disk however-- but when you absolutely NEED to get $FOO running, because busybox does not have it compiled in, or you need some special service to start, the repository access is very handy.
Again, because it installs into a user-specified directory, it is a ready made chroot ready to be jumped into. I have a debian chroot on my consumer grade wifi router, which I use for all kinds of fun things. It sits alongside openwrt without issue, and keeps the flash clean from extraneous stuff. It sits on the small USB stick I have stuck in it.
The real point I was making though, was that debian was a REFERENCE DISTRO.
It does NOT fall into the "Desktop" or "Server" category. It is "Reference". Debian is neither a really good desktop (older, more mature packages, which means spottier driver support), nor a really good server. What it is, is a good reference platform from which to BUILD a specialized distro.
Many systems are based on debian. Decisions which impact debian will impact those other downstream distros. Not all of which will be too pleased with including systemd.
Debian has its niche. Much like the argument about vi and emacs, the init vs systemd argument will not go away. That's why reference distros like debian should support both without favoritism. Any downstream distros that use them as the reference can pick as their userbase deems appropriate.
The "Remove the fragmentation!" rally cry fails to capture that "homogeneity is not always good" and is in fact, the antithesis of "choice."
Re: (Score:3)
Bollocks. Debian is an EXCELLENT server. It's stable, bug reports are fixed quickly and the software is well tested. If you want a reliable server Debian is where it's at. Based on the number of Debian Servers out there in the wild I'm not alone in my feelings about Debian.
Parallel booting of services (Score:3, Informative)
The idea of booting services in parallel is nice, but the problem is that apparently it doesn't have a way to specify that you need to wait for a dependant service to hold off until the initialization of the dependancy is complete. Systemd considers it "booted" as soon as it launches, which causes people problems with unreliable network initializations and such that have been resolved for Sys-V style init scripts for years (if not decades.)
Re:Parallel booting of services (Score:5, Interesting)
Wait, what? It's the other way around. If the dependencies are systemd managed, systemd will wait until they report back to be up and running before starting dependants. This is opposed to the SysV rc way, which just blithely ignores all output and continues booting unless the rc script actually hangs.
In fact, one of the most common complaints is that systemd keeps hanging on filesystems in fstab that are not mandatory to mount on boot, instead of ignoring the mount error and leaving them to be mounted manually later.
Re: (Score:3)
That is absolute bollocks. You have to go out of your way to put the init programs in the background with SysV init scripts -- they don't return until initialization is actually complete.
Parallel booting of services (Score:3)
Wrong, services are considered "booted" when they are ready to process requests. For most services, the kernel kan be made to "buffer" request, so we don't care in which order they are started. For those rare cases when we do wan't to hold off a service, the unit-files can specify exactly what to wait for.
Oh, and by the way Sys-V init scripts never solved this. They depended on the daemons to solve this, which they virtually never did. Or sprinkle the init-scripts with strategically placed sleeps. This resu
Read of the better systemd commentaries around (Score:5, Informative)
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
This comes from an "anti-systemd" source, but tries to cut through a lot of the controversy and hostility shown on both sides. Bear in mind, you only see the anti-systemd view on Slashdot, but you get just as much idiocy on the other side as well. For example, the Poettering "death threats" were actually a joke made by a bunch of people in an IRC channel. Here, read the log (ctrl-F "hitman"):
http://logs.nslu2-linux.org/livelogs/maemo/maemo.20130215.txt
Re: (Score:3)
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
This comes from an "anti-systemd" source, but tries to cut through a lot of the controversy and hostility shown on both sides. Bear in mind, you only see the anti-systemd view on Slashdot, but you get just as much idiocy on the other side as well. For example, the Poettering "death threats" were actually a "joke" made by a bunch of people in an IRC channel. Here, read the log (ctrl-F "hitman"): http://logs.nslu2-linux.org/li... [nslu2-linux.org]
FTFY. Sorry, there are some things which just are not funny, and if we're gonna condemn idiots like Sam Biddle who tweet "bring back bullying" and other such nonsense (hint: the backlash was rather large), we should also condemn people "jokingly" saying they're gonna put a hitman on anyone.
Plays nicely inside a container (Score:5, Informative)
I've been starting to migrate many of my services at home to containers to make them a bit easier to maintain (a bit of a tangent - having 5 containers instead of one host with 5 services means that you have to do 5x as many updates, but each update can at most break one thing at a time). This was trivial to do with systemd-nspawn.
With a command line that barely fills a terminal line I can launch a container, have it boot systemd inside the container, have a few bind mounts, and have it get its own IP like a lightweight VM. Within the container systemd just does whatever it is told to do, like launch ssh so that I can get in, configure the network, and launch whatever services the container was intended to provide. The container journal logs are symlinked back to the host log directory, so they're really easy to look at from the host.
Sure, you can do similar things with docker, but doing it with systemd involves less tooling in general.
Also, for simpler situations systemd-nspawn makes a VERY good substitute for chroot. In addition to doing everything chroot does, it starts a separate process namespace so you don't see outside processes from inside the container. It also automatically sets up /dev for you, sets up resolv.conf, etc - it can do all this while just spawning one program inside just like chroot does (so no need to run systemd inside). It can also set up bind mounts if you ask it to. When you exit it cleans up - no lingering bind mounts, or tmpfs, or /proc and such inside. Also, any mounts inside the container aren't visible outside, so you can run a backup on your chroot and not have it follow bind mounts, or try to save /proc/kcore or whatever. In fact, you could spawn 5 containers inside the same directory and they can have private /tmp and /dev and /proc while seeing changes each other make in the files in the actual chroot.
Stop means STOP (Score:5, Informative)
One thing I really like about systemd is that when you stop a service, it actually stops.
I used to run monit with openrc and when you wanted to restart a service you had to play games to ensure that it was really killed, and that the service state was cleaned up, and so on. Just telling openrc to stop the service just wasn't reliable at all - it worked well when nothing was wrong, but if nothing was wrong chances are monit wouldn't be doing anything.
Systemd is very effective at containing processes and their children and when you stop them, they are all gone for good. If you want to restart a service, systemctl restart service will get the job done 100% of the time, assuming the configuration/etc lets it restart. It does support graceful shutdown of individual services, followed by process genocide.
This also applies to things like cron jobs you launch through it. When the parent process ends, anything left gets cleaned up.
Hardening (Score:5, Informative)
Systemd was forced down my throat by Arch Linux. I didn't know anything about the controversy back then, so I just thought: "There's probably a good reason for this, let's get to work".
I read some docs and I liked the security features a lot! You can tighten services easily with a declarative syntax.
Here's a snippet from my ntpdate.service file. You don't need much systemd knowledge to guess at what each line does:
PrivateTmp=true
ReadOnlyDirectories=/
InaccessibleDirectories=/boot
InaccessibleDirectories=/root
InaccessibleDirectories=/etc/ssh
LimitNPROC=1
DeviceAllow=/dev/null rw
DeviceAllow=/dev/urandom r
User=nobody
Group=nobody
CapabilityBoundingSet=CAP_SYS_TIME
NoNewPrivileges=true
I ended up enjoying that work and tightened things so much that I hit a bug, which was resolved in just a few days: https://bugs.freedesktop.org/s... [freedesktop.org]
But I still don't know how to configure the network properly T_T
Re:Hardening (Score:4, Insightful)
Those facilities are not given by systemd. They are given by cgroups and other security features. Systemd just has a way for you to specify them for services, it's not doing all of the heavy lifting.
Similarly, imagine that config file, interpreted by SysVInit scripts, and applied the same. Would that be better or worse than systemd?
And, to be honest, in terms of the userbase, that's quite a niche preference. I can count on my fingers the number of times that I've personally had to lock down a service to the bare essentials. That's what package managers and SELinux policies are for.
Again, it's a lovely feature. But does that justify ripping out the init code from the entire distro for? And could it be done any other way (I'm guessing yes).
Re:Hardening (Score:5, Insightful)
Wait, so now we aren't setting read/write status in fstab anymore?
How do you set filesystem read/write status for just the ntpdate process in fstab?
Speed (Score:5, Interesting)
Just installing systemd over sysv speed booting up from a minute to 10 seconds, and shutting down from half a minute to under one second. I always hated Linux couldn't handle shutting the fuck down efficiently, now it does.
Re:Speed (Score:5, Informative)
I've killed systemd shutdowns hard after 15 minutes of timing out waiting for an nfs share that went offline.
The old system didn't do that. Not to detract from the lovely startup times, but it's not "all baked" yet.
Re: (Score:3)
This sounds like a bug. Systemd is new, so it will have bugs. This is not, however, a design flaw. It is merely something that needs to be fixed. It's only a major problem if the devs refuse to fix it on the grounds that they don't think it's a bug. However, I've mostly only encountered that attitude when reporting Chrome bugs to Google.
Exit codes matter (Score:5, Informative)
A small thing I've come to appreciate with systemd is that it actually cares about exit codes. This applies to any unit, including timer units (the equivalent of cron jobs). I ported most of my cron scripts over to systemd and suddenly started noticing scripts which had been having non-zero exits for ages, but fcron just didn't care about exit codes.
You can tell systemd to ignore exit codes for a process, or specific exit codes. However, I've found that in general using systemd I have a lot more awareness of abnormalities in my services.
Sure, you can often get away with ignoring exit codes, just as you can often get away with ignoring compiler warnings. However, in getting rid of them I fixed a few problems ranging from trivial to important, and my system is more robust for it.
Service files are easy (Score:4, Informative)
Writing service files for my own daemons or modifying existing ones is pretty close to trivial. The files are short, easy to understand, and there isn't any risk of runaway child processes like there is with a sysvinit init script making them close to trivial to write and maintain. If anything I would say that's why so many distros are jumping on board.
I had to write service files as an early adopter, but it would also be useful for anyone rolling out their own daemons or that needed to tweak the behaviour of an existing service for their own needs. I imagine it would also lead to fewer packaging bugs.
VERY POSITIVE: Systemd is well-modularized (Score:5, Informative)
Systemd is modular:
- It's broken up into multiple independent processes, each of which handles one major thing well.
- It's broken up into libraries so that commonly used code (such as parsing config files) is implemented once and shared among the services, saving memory (because you know how shared object libraries work, right?) and ensuring that there's only one implementation of any one thing that needs to be tested and debugged.
- Interdependence among services is minimized, although as with any real, complex system, there are chains of dependencies.
- Dependencies on and among services are handled on-demand so that only the services you need are running (often started well after boot). As a side effect, boot time is shortened.
- Process 1 (init) is very small, with minimal functionality, in order to minimize the chances that it will crash.
The above are all true, or at least they are consistent with claims made by the developers. Sure, I have negative things to say, which are also true, but I don't want to add to the noise of all the false negative claims floating around.
Re:VERY POSITIVE: Systemd is well-modularized (Score:4, Insightful)
Wow. The usual complaint is the myth that systemd is monolithic. It's not. But now you're complaining that it's broken up into too many services? And how is this any different from sysvinit, which also starts any number of different binaries?
All they've done in systemd is write C code to start up services that used to be started instead by shell scripts and added the ability to make dependency resolution automatic so that services are only started when they need to be. So basically, they made it smarter and faster. The complaint that it's got too many binaries is moronic and a complaint just as well against sysvinit.
Systemd is modularized into a number of different binaries, each of which handles a different service. Thus, different functions are isolated from each other. This enhances stability and improves startup performance when not all need to be running first thing at boot time.
Oh, and all of systemd's config files are written in ASCII, in the traditional UNIX way. One cool thing they've done is made a single parser implementation (in a shared object library) so that all of the config files have the same syntax. Also, when you debug a problem with parsing for one service, you automatically debug it for all others at the same time.
I #*@%ing like it because... (Score:3, Funny)
Visability into the boot (Score:4, Interesting)
Systemd during a normal boot is doing some detailed logging of the boot process that let's you do a simper version of bootchart. This allows you to find out how long each service took to boot and also do a graph of them.
It's concerned complimentary to the actual bootchart...
[1] http://0pointer.de/blog/projec... [0pointer.de]
Sophisticated Process Group Leader (Score:4, Interesting)
Back in 1993 I worked on a network process controller for Inmarsat-A. It had it's own custom init process group leader which erected unix domain IPCs between certain children, some shared memory segments, and performed a waitpid to relaunch any child process that died. I was new to the project and new to unix so when I suggested we use inittab to take over this task, the team lead just laughed. Init was not up to the task. The arrival of systemd finally addresses this use case: a process group leader that can care for of a hierarchy of tightly coupled processes. Systemd may be complicated, but so is the intended use case.
I can say something nice (Score:3)
Having read the myths page I largely believe it was the right thing to do. Linux is a living operating system and sometimes it has to be dragged kicking and screaming away from things that may have been acceptable in 1990 but not when going against other modern operating systems. Wayland is another ongoing example of that and I'm sure that once it becomes the default choice in some dists that we'll see people being extremely vocal about that too.
The best thing about SystemD is. (Score:4, Interesting)
Why dislike something you know nothing about? (Score:5, Informative)
Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)
Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.
Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.
Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.
So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).
http://0pointer.de/blog/projec... [0pointer.de]
http://0pointer.de/blog/projec... [0pointer.de]
http://0pointer.de/blog/projec... [0pointer.de]
http://0pointer.de/blog/projec... [0pointer.de]
http://0pointer.de/blog/projec... [0pointer.de]
Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:
https://access.redhat.com/docu... [redhat.com]
Here's the project page with loads of links about the software and uses cases:
http://www.freedesktop.org/wik... [freedesktop.org]
And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.
http:/ [0pointer.de]
Process management in a consistent way (Score:5, Interesting)
OK I'll try this. Traditionally Init services were about starting processes. They didn't have capacities for keeping processes running. Which meant that for processes that need to be kept running and for which there was a real possibility of failure (most of them) the init had to start a process management system which then started the functional process. This has been the status for years. With systemd there is a process maintenance component standard in the init system. Which means that processes not only start but are capable of being kept in a stable state easily and automatically. Process management stops being something system admins work hard at and instead becomes something that happens out of the box.
Journalctl logging is more secure (bug #1098132) (Score:5, Informative)
Caveat: I am a server admin.
With systemd, one can't even remotely log a journal natively, which is par for the course in many server environments. You can't make this stuff up, please see bug #1098132 (https://bugzilla.redhat.com/show_bug.cgi?id=1098132) At the time I'm writing this, that functionality still just *doesn't exist* in systemd/journalctl. It was almost pushed into the last revision, but the bugs were show-stoppers so was pulled. Even if it does go into the next systemd revision, how long until it's really kosher for solid/production environments? 1 year? Two? Three? Yet it's being pushed as the default *now*.
To explain why this is important: if someone cracks in, the log files are going to be one of the first things they muck with. You have locked down syslog/et al, so you can tell if they muck with the binaries, but the log files themselves are considered compromised. Logging remotely at the same time before the data even hits the disk creates another layer of safety, which you simply can't do with systemd/journalctl. One day you will, assuming you want the binary journal and journalctl, but even if you wanted those now you couldn't. Yes, you could rsync over a copy of the files, but there's a reason why people aren't just doing that for regular logs and this is going long.
Over the last decades, people have worked out tried-and-true systems for documenting and verifying logging. So from an audit perspective, with journalctl you can't lock down syslog-ng and that process, because you've introduced an untrustworthy one above it. They know the current strengths and limitations -- to the point that there are legal/liability issues involved for many if their logging goes wonky. Journalctl adds a layer between the systems they have that work (and even have protocols in place for in terms of auditing), and as of right now adds a *wonky* layer that's very buggy. And by buggy I mean prone to corruption and simply not doing as its told.
Here's the real kicker: most of this issue would go away if systemd was willing to allow the user to not use journalctl and let things like syslog-ng have that data in the raw. It is choosing not to allow that as a tactic, as opposed to what the users and tech itself wants, and so here we are.
Also, this entire proposition by samzenpus is inane. When one thinks backwards from what the motivations might be, none of them are good and make me lose that much more respect for the site.
Re: (Score:3)
Caveat: I am not a sysadmin. But I have read up on SystemD.
With systemd, one can't even remotely log a journal natively
Why not? SystemD offers its own logging system, but does nothing to prevent you from installing a more capable logging daemon such as rsyslog.
Note that before Fedora 20, rsyslog was installed by default, along with the SystemD logging. In the announcement it says:
Its going to make 2015 ... (Score:3)
downgrade. (Score:4, Insightful)
Systemd Does Not Cause Ebola (Score:4, Funny)
To date, there is no evidence that systemd causes ebola.
systemd is Linux logging done right (Score:5, Informative)
systemd's logging system is a huge improvement over old legacy style text logs. It has more early boot logs since it can log while still in initramsfs, and with kdbus it will probably get even earlier and late logging; the goal is "metal-to-metal" logging.
Having structured and indexed logfile (called journal) is a huge improvement in many ways; it allows for rich meta-data like monotonic timestamps, high precision time stamps, UUID's, exe file names and paths, and incredible easy and powerful sorting and filtering with tools like "systemctl".
If you try to add meta-data like monotonic timestamps in flat text files, they become very long and cluttered, making them hard to read for humans.
Another problem with flat text files are the fact that watch scripts depends on the exact wording of the daemon output strings; if the developers changes the wording, third party scripts will fail. In a perverted sense, the exact wording have become a API that cannot easily be changed or extended.
Not so with systemd; it has a stable API and lots of language bindings. It is easy to make a watch script that targets the stable field's.
Some CLI examples: I have used full length options for readability and since systemd have excellent bash completion for everything, it doesn't involve much more typing.
journalctl --boot -1 --priority err
Show all log entries from previous boot only, that have log level "error".
journalctl --since -5m
Show log entries generated the last 5 minutes.
journalctl --follow --unit smartd.service
Follow (tail) the smartd daemons log output.
journalctl _KERNEL_SUBSYSTEM=usb --priority warning
Show only messages generated by the kernel USB subsystem that have log level "warning"
journalctl --field _PID
The "--field" option makes systemctl show all values of the following journal field. In this case it will show a list of all PID's that have ever written to the journal. Want to see every executable that have ever generated log output, substitute _PID with _EXE. Notice the underscore. Field values with underscores have kernel guarantee for being correct.
It is also easy to track two services that you suspect are causing each other problems:
journalctl --output short-monotonic --boot -u NetworkManager.service -u chronyd.service
This will show the log entries for NetworkManager and a sNTP client from the current boot, and show the output with monotonic timestamps. Nice.
Thinly Veiled Attempt... (Score:3)
The only good thing I can see about systemd is the exposure of some Linux system APIs that were not exposed via the POSIX subsystem. Nice - but not required by most of us - and could be added to existing standards based initialization daemons without totally rewriting the rules.
Otherwise it seems to be more likely a thinly veiled (actually not veiled at all...given comments of the principles) attempt to fragment the POSIX world - and forcing projects with limited resources to make a Hobson's choice of whether to support systemd based Linux or POSIX standards exclusively. It breaks write once - compile/run anywhere - that was generally available for those who made sure their applications were POSIX compliant. This means that a lot of software that was available across Linux, and Unix flavors (BSD) will now be exclusively available on one or the other - thus fragmenting the *nix world.
Software is not separate from the ethics that surrounds it. This approach and apparent rabid anti-interoperability view is arrogant and self-serving at the expense of cooperation and choice. Furthermore, the monolithic architecture, obfuscated binary logs, and centralized configuration are antithetical to the Unix way - and makes a linux system as difficult to deal with as a Windows system from an automation and management perspective, and raises concerns in terms of security (the greater the complexity in a system, the greater the opportunity for bugs - and thus the greater the attack surface).
Finally it throws away many many years of experience/knowledge acquired by system admins, developers, and users about how a *nix system operates and is configured. This fragmentation of the human factors aspect will by its very nature cause faults/issues during operation.
So - for a host of reasons, I believe it is technically - and more importantly - ethically wrong.
There is actually one more good thing I can think of: it will spawn new distros, software projects to provide alternatives of various applications in the stack, and perhaps new operating systems altogether - with a renewed focus on design simplicity (KISS) and all of the benefits that come from that. Once a system becomes too complex to understand - are you sure you can trust it? So to recap: systemd has two things going for it; exposure of Linux APIs, and the power to breath life into the further exploration of alternatives in the OS/application layer.
Less fragmentation (Score:3)
I like the fact that systemd's wholesale acceptance by all major Linux distros means much less fragmentation in both the way the Linux OS is managed and the easy that upstream projects are now able to support advanced features in a distro agnostic way.
I also like the fact that it exposes advanced kernel features like "cgroups" and "Capabilities" and make them easy to use; just add a keyword in a text config file and restart the service.
Add ProtectSystem=full in a service config file, and the service and all processes it makes can only "read" /usr and /etc enforced by capabilities. So even if the service is compromised, the hacker can't modify these directories, even if the hacker are able to execute code with root privileges.
http://www.freedesktop.org/sof... [freedesktop.org]
Also "ProtectHome=" makes the service unable to read /home, so that no information stealing can take place.
Perhaps the best thing about these features and the many other systemd features like those, are that they can be enabled by either upstream or the distro makers, so that the end user doesn't have to anything in order to improve the system security. It will simply mean improved security and "defense-in-depth" as deafault on systemd distros.
Systemd has more than halved the reboot wall time. (Score:3)
I have an RHEL 6 system with multiple commercial Java applications. For some reason, every commercial Java application out there seems to bundle half of a linux distro with it: they insist on using their own instance of a web server, their own application server, their own database, their own mail daemon, etc. Starting those things serially is true insanity and takes forever.
With all of this stuff migrated to RHEL 7, tweaked so that there's no init + rc.d craziness left, a 4 minute boot-up turns into 1:30 boot-up. This is with spinning drives. I have another iteration of tweaks where I exposed all internal service dependencies inside each of those monolithic app monsters to systemd, and we can be up and running in 1:15. Looking at I/O statistics, with further judicious use of preloading we should cut it down to 1:00-1:05 after a clean shutdown. The shutdown times, usually well over 2 minutes long, are down to 30 seconds.
This is all measurable, no-bullshit, experimental data. We even managed not to have to touch any of the commercial app's rc scripts, I simply coded up the requisite systemd configurations for those services, based on the rc scripts. If there's any question as to systemd's effect on the application, or if we need to deal with vendor support, we can always start it up using the rc scripts.
So, I don't care about ideology behind systemd, and how it fits with someone's ideas about what Unix or a Linux distro should or shouldn't be. All I know is that it'd have taken me 5-10x as long to tweak the system rc.d scripts to parallelize them than it took me to "port" the commercial apps we use over to systemd. Of course the distribution's own services already use systemd, so I didn't have to touch that, only tweak a few things slightly to further leverage parallelism. It has saved us time and money, and the system availability is much better in face of the rare reboots. Everyone is happy. We're a small shop with a single server, and we use no virtualization nor any other enterprisey stuff. Just a plain old RHEL 7 running directly on hardware, with selinux turned on, with custom policies written for each of the commercial apps.
A lot of the "recommendations" I've got from "veteran" admins essentially reduced to throwing money and resources at the problem. That's IMHO a rather direct vindication of systemd: if it takes a SAN, multilevel storage and VMs just so that the damn init/rc.d-based system will boot in a reasonable amount of time, and all of that is taken care of by systemd, it'd be rather irresponsible for me to try and ignore systemd. In the name of what? Nothing I can think of. It's not like I can tell the management "hey, RHEL 7 comes with systemd, but I can keep using RHEL 6, not use systemd, and spend $25k+ for a SAN, VM and OS licenses, and the time to set it all up and document it all".
<rant> It takes some chutzpah for commercial vendors to claim RHEL 7 "support" in their solutions, if they support neither selinux nor systemd.</rant>
Re:Where do you think you are? (Score:5, Insightful)
What the fuck, you think you can set rules for discussion on Slashdot?
Sadly he can't force the rules on anyone, no matter how useful those rules would be for such a debate. So, instead of actually doing what the poster wants, we instead get comments like yours which add absolutely nothing to whether or not systemd is any good.
And yes, it's a question I was considering posting on too. It would be nice to see some useful information.
So thanks for clogging the top level posts up with useless, pointless crap. You have done your fellow slashdotters a great service showing you can be angry on the internet.
On a related matter: (Score:4, Insightful)
With more people jumping to FreeBSD, we might get better hardware support over here.
Re:Sure. (Score:5, Funny)
Or even better : The nice thing is systemD is not portable. It will infect only linux.
Re:Sure. (Score:5, Interesting)
Re: (Score:3)
Why do we have to mention Bennett in the non-Bennett posts? can we just have a break please?
Re: (Score:3)
Bennett provides a service.
Mosquitoes provide a service.
systemd provides a service.
Let it be.
Re:What system d really is (Score:5, Insightful)
The reality is that before systemd showed up, there wasn't really any project with an active upstream that tried to solve the plumbing problem (I'm not talking about init in isolation here). Each distro had to invent their own hacks, some of them good, some of them not.
The fact is that the community that is beginning to form around systemd is much more healthy than the scattered bits and not-quite-fitting pieces we had before. Maybe that's sad, I don't know. I think that in the end, the unification around systemd will allow competitors to form (just implement the interesting subset of the systemd interface and you can integrate with all distros!). So long term we'll end up with a much more vibrant plumbing for Linux.
Re:What system d really is (Score:4, Insightful)
For those who think SysVinit style init systems is what Linux should be using the next 30 years, there is Slackware. It is a nice general purpose distro that is very traditional. So nobody is forced to use systemd if they don't want to.
Until some key functionality used by people is no longer available in that distro due to decisions made upstream to no longer support the code base, or other dependencies. [slackbook.org]
If I use KDE - which I do - then packages for that become unavailable at some point in Slackware given the above. That means I will be forced to use systemd if I want to continue using KDE; which also means I will have to change distributions, assuming Slackware remains systemd free, as well.
Not trivial. Not easy. Not freedom of choice.
That is simply a lie.
Re:I'll explain it this way... (Score:4, Interesting)
Your history is a bit off here. Linux's earliest intent was as a workstation OS. An operating system that Unix users could administrate and on their x86 box. A $2k alternative to buying a $7k Solaris workstation. RedHat itself came from this desktop mold, before the LAMP stack made the real action cheap server alternatives. Mandrake, Caldera Desktop, Corel Desktop were all doing easy desktop before Ubuntu. What was unique about Ubuntu was: it was free and gave away the CDs. Everyone else was trying to make money selling the operating system.
What you are right about is that Ubuntu created a generation of Linux users with no experience with other Unixes or often other Linuxes. In so far as Linux was ever successful on the desktop Ubuntu was the form of that success. Your paranoia about "disruption" and "the establishment"... is simply that. Exactly what do you think in the 1980-90s you were doing to the mini computer culture of the generation before you when you made client server cheap and ubiquitous?
For example, RedHat in 1994-6 was selling a commercial X-Server as an option because XFree86 was too hard and too crappy. That wouldn't have been the case if no one cared about ease of use or just doing bug reports.
____
As for the "no plan" that was part of Linux culture from the beginning. It was one of the things that distinguished the GNU community from the 386BSD guys (and the children that spun off to be the today's BSDs).
Re: (Score:3)
So, the nicest thing you can say about systemd is an ad-homenim attack on people who don't like it?
And I wonder why systemd threads end in massive flame fests.
Re: (Score:3)
Did you ignore the first paragraph?
Yep, but I fooled around with hotplug a while back. Bsically it resulted in a shell script being called. So you could execute arbitrary code on a hotplug event. Sure it might be nicer in systemd, but doing it at all (what you mentioned) was certainly -possible- before.
So since what you wrote was not actually an advantage of systemd the way you said it, I decided to ignore it.
That left a massive blob of ad-homenim attack on people who don't like systemd because they hate n