Em .. no, thank you.
I think that systemd is a good step in the direction of unifying different distributions. Also, many argument presented on that page have been debunked or are actually good things.
I think the concern is that systemd is following a rapid "embrace, extend, extinguish" path, and very quickly will have achieved critical mass and become somewhat unstoppable.
There's nothing wrong with saying "I like Linux, but it's becoming Lennartix and I'm concerned."
They made the only choice. Because various applications are now dependent on systemd APIs in order to function correctly, and those APIs in turn can only be implemented by an init system that is structured the same way as systemd, it's essentially impossible to use anything else. Someone could come up with an alternative to systemd that was superior in every other way and it'd be impossible to move to it. (Hell, it'd have been impossible to move to systemd in the first place if the existing init system was so closely entwined with everything else.)
Already the reason 1. is crippling Linux and what it stands for. All points combined mean that if you include this in distribution, that distribution will stagnate and die.
I think diversity is one of Linux's strengths. And the flexibility is what allows people to experiment and try create new things, wildly different and original things. Things like new init systems, say systemd. I don't mind what init system you use, but it would be nice if one didn't become the dependency that is so hard to replace or work around that no sane person will. That's a way to kill innovation and ensure that big changes only come from the influential elite.
I'd rather see init's problems fixed (i.e. start services in parallel), but systemd is far better than upstart (edit: got it to load at last, I see it's not by upstart fans, so ignore that last part).
That said, a lot of systemd seems like a really stupid idea to me, e.g. binary logs, the massively increased SPOF size, and the "do everything" mentality. Unfortunately, I don't know of any distros that aren't using it now (edit: I didn't even realise Slackware was still a thing...), and upstart is even more of a joke than systemd.
I've got to agree with a lot of your points here, to paraphrase churchill, systemd is the worst system management daemon system that we have, except for all those other ones that have been tried from time to time. (this sounds a little harsh to the other ones, but I find systemd intuitive from a user-facing perspective even if it does have a lot of inelegance under the hood)
[0] http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...
What's wrong with binary logs? Seems like an improvement, given how they can be cryptographically 'sealed' to help tamper detection, and have indexes built in [1].
Binary logs are pretty annoying because your standard tools for searching through them no longer works.
tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.
> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
Actually, they won't. Because journald has the relevant functionality built-in -- that is, it can automatically stream out the logs in any format you choose, including ones understood by rsyslogd, and if you really just don't like journald, you can just turn off it's storage and turn it into nothing but a shim.
So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo.
> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that.
Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information.
Regarding the last point, here's an example of an entry from journalctl -o json-pretty:
It sort of okay when you only have one system that does binary logs, but what if you have 5 or 10, each with their own log format and little tool that I need to pipe the log file through?
The binary logs also assumes that you actually know where stuff is or that you're not going to look across multiple systems in one go. If you're large enough you'll have logstash/splunk or something similar where you have already de-binarized the log and this become less of an issue.
But for may of us doing a "grep <something> 2014-04-*.log" is something that's just natural and we come a bit hostile if you're trying to take that away.
That being said I think systemd might have a way of just giving you the log in plaintext.
You can still use those tools if you want, just pipe the output of journalctl, and use journalctl -f in place of tail -f. It's faster to filter logs using parameters to journalctl though, as it can use the indexes.
Also, systemd writes syslog style plaintext messages to an IPC socket at /run/systemd/journal/syslog if needed for compatibility.
0) it is hotplug capable
1) we can know the state of the system
2) it is modular
3) it allows dbus/udev to go back to doing the task they are meant to do
4) we can reduce the number of explicit ordering dependencies between daemons
5) we get a lot of security/sandboxing features for free
6) systemd service files can be written and distributed upstream
7) systemd is a cross-distro project
8) logind will finally deliver on what consolekit was supposed to do
9) systemd is fast
I'm very excited about dmd. It's being developed in conjunction with the Guix project for an official GNU distribution. I hope to soon steer clear of this systemd mess by using a Guix system running dmd.
Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins.
Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
Yes, I've looked at it. You need to understand that dmd is still a fledgling project. Note the version number before you trash a software project. It lacks the features of the popular init systems, but it works well enough to run some basic services on the demo Guix VM images.
I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
Data-based formats are most useful when you know all the requirements one will need up-front, because they need to be coded into your "schema" or DSL - these schemas quickly break down when you have new requirements - and initialization is an extremely diverse area.
The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software.
It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile.
As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.
0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own.
1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common)
3: This is a strange claim when talking about an init system that effectively starts managing devices.
6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again.
8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here.
There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...
0: Kay wrote udev. He is now a lead contributor to systemd...
1: Upstart was hobbled by the Canonical CLA. Several systemd contributors cite this as the reason for starting systemd in the first place.
3: See 0
6: See 1
8: logind is developed as part of the systemd suite, but is entirely modular and in fact is used with non-systemd inits via systemd-shim.
I don't believe the CLA was the main reason for starting systemd. Otherwise they'd just fork upstart and continue to work on it without signing anything. CLA has nothing to do with technical features either.
I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system).
If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.
From Scott Remnant, who wrote Upstart when he worked at Canonical[1]:
"I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA
If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :)"
The CLA is absolutely why systemd exists. systemd didn't fork because there was no benefit to anyone in sharing code -- Upstart wouldn't take their patches. There are technical differences, but those could have been handled in code (like Scott says) if the CLA hadn't existed.
I just don't buy it. The license allows them to clone upstart. Why would they care about upstream taking their patches if they were ready to start a new project anyway? If technically there was no problem for upstart to be the successful project, then what was the reason they didn't simply rename it and start from there? Dropping the whole history and starting from scratch doesn't seem like a reasonable choice in that case.
...so you're saying that you don't buy the statements of both the people who started the systemd project AND the person who was running Upstart at the time, about what prevented them from collaborating?
Not about what prevented them from collaborating. The original claim I disagreed with was "Several systemd contributors cite this as the reason for starting systemd in the first place."
This does not make sense to me. They could fork it if it was good enough. If they started from scratch, then CLA wasn't the main issue. It's like "the corner store didn't have the milk I like today so I had to start my own farm".
This really isn't difficult to understand (again, just read the link above, the people actually involved go into it). The systemd people believed there were technical flaws in Upstart. They talked to the person in charge of Upstart, who was amenable to their points. They looked into collaborating, but the CLA stood in the way of that.
If there was no CLA, the folks who went on to develop systemd could have decided that the benefits of collaborating with an existing project were greater than the benefits of writing systemd from scratch. And everyone involved seems to agree that that's what would have happened. Yes, as a purely technical matter, the systemd people decided starting from scratch was better than forking Upstart. But the reason it was a purely technical decision was their refusal to sign the CLA, which meant the ONLY considerations were technical. But there are other considerations that could have swung the decision the other way if not for the CLA.
>Kay wrote udev. He is now a lead contributor to systemd...
Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.
Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).
Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.
From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.
0) That's not the init systems job.
1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html
2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
3) See 1.
4) Never bothered me, but fair enough.
5) That's not the init systems job.
6) Not if the path's differ. E.g. are debianized.
7) So was sysvinit.
8) That's not the init systems job.
9) It actually is.
Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.
> daemontools are nothing more than an init system on top of an init system
What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).
I've been using s6 to manage a few things, and some features I like are:
- allow a group to manage (stop/restart) certain processes using Unix file permissions
- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors:
The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.
> 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false.
dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd).
It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition.
systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite.
Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.
Various core system bits that are tightly integrated using undocumented APIs and assumptions about what the other parts are doing internally which are subject to change at any time. I think you can replace some, though not all, of the non-PID-1 bits with a little development work, but replacing the core parts is unsupported.
That is beside the point. The argument was "That's not the init systems job." to which I presented the counterargument that systemd is not just an init system.
See my comment at https://news.ycombinator.com/item?id=7639730 - those are the external APIs used by software that isn't officially a part of systemd but still depends on it. The APIs between different parts of systemd are undocumented and subject to change. In fact http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... says as much itself and exists in part to convince people this isn't a big deal because in theory someone could write their own components that implement the same APIs. (Except that in practice no-one has reimplemented anything beyond the most trivial APIs, and in fact that page claims some critical stuff like logind cannot be independently reimplemented or used without systemd.)
The systemd init is FAR more complex than a basic init.
Service status management? service file (of all types) parsing? IIRC all done in PID 1, with a nice (?) dbus integration and a glib loop added in for some additional fun.
Some think this is dangerous and not necessary.
If over half your critique is that systemd does _more_ then its predessor and all of those are valid services, that it can do well, then I don't see the real complaint here. I mean are you upset because its different.
It's only better if it does a better job than the tools it replaces. I have working dhcp, cron and logging on all my systems (well, those that need dhcp anyway). I can replace them fairly independently. Why would I want to entangle them? And not only does the the tool need to do a better job at all these things, but it also needs to remain flexible, and easily tunable -- for it to be overall better.
I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.
For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.
From a desktop Linux perspective, you're totally right. However, if anything is evolving fast, it's the recognition that desktop Linux has never worked and will never work, and is in any case the extreme minority case in modern Unix systems (which, population-wise, are essentially all embedded systems, servers and phones).
From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable.
Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.
> the idea of hotplug at all is the least of concerns
No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one.
Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.
Although I haven't had anything like that happen in my 26 years of running unix boxes and marvel that it has reportedly happened to you, I agree that there is room for better dependency management in the startup process.
That nevertheless doesn't have anything to do with hotplugging devices, nor does it suggest that we should create an init system which handles dhcp, qr codes, and, no shit, takes core files and jams them into its binary log.
For me, systemd broke beautiful Arch setup into some monstrosity. That's not what Arch was or at least what it was for me.
I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?
I keep hearing bullshit about how systemd broke archlinux. But for the vast majority of us it did not. I had atleast 3 machines running ArchLinux at that point and had very little trouble porting all of them.
Anecdotal evidence can be dismissed by anecdotal evidence -- A variation of Hitches' razor
Switching to systemd broke _my_ entire Arch _experience_. Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
and look at its contents. It is not that hard. It changed everyone's experience. Some people just hate change. Others deal with it.
While it did make desktop / laptop users experience a little bit more complicated, from what I have read it makes things much easier on the sysadmins who are working with lots of daemons on the servers.
I understand what you mean. I had the same awe when I first started on Arch and really got to know all the bits and pieces. When I transitioned to systemd, I had to go through that again. It was actually very similar to what I did the first time around and I suggest you give it a shot too. systemd, while seemingly monolithic is actually a really cool suite of tools. The thing we need to keep in mind is that it's _not_ sysvinit, and it's not trying to be. It's trying to be a project that does more than that and does it transparently on all systems. You might like it :)
As a general point for everyone: Just because it's _also_ an init system doesn't mean it's not allowed to provide the binaries for doing a whole lot of other stuff. :)
The problem is that it's a suite of tools that are all developed under the same umbrella, by the same people, with the same ideas, and the same gatekeepers. It's rather difficult to fully replace parts of it, especially as the formal API to it is defined by systemd, and we're seeing more and more tools integrate with all that.
Why can't we have an independent organisation that defines a spec for all the relevant APIs and tools for managing a system, and systemd just be one implementation of that spec? Actually, it could be a suite of specs, so people could pick and choose which ones solve their problems, and build alternatives for others.
Hmmm... I pondered this for a bit, and I arrived here:
> [...] by the same people, with the same ideas, and the same gatekeepers [...]
Isn't this exactly what made the Linux Kernel great? A consistent vision.
I agree with you on a few points though, the systemd team should be more cooperative and start being conservative on the API changes. If the API is defined clearly, it shouldn't be hard to make proper replacements for parts of it.
I disagree strongly that there should be an independent Organisation to define that spec, because that would quickly be overrun by bikeshedding and all the other problems stemming from design by comittee. Very often in the Open Source world, specs have been defined by the first people arriving at the scene, so to speak. It all works over dbus, no? That is a fairly simple protocol to implement. I think it's an elegant IPC solution.
> Isn't this exactly what made the Linux Kernel great? A consistent vision.
Sure, but even today, the Linux kernel has competition. I can run most things on Windows or OSX or FreeBSD or Solaris, even if the technical details are different. I worry about a monoculture forming around systemd, as seems to be happening now; I can't find a modern distro that uses anything else (aside from Gentoo, which I can't take seriously for production work), and it's starting to be assumed that systemd is the only init system that anybody will use.
It's not that bad. rc.conf had its own problems. Remember the archaic format of specifying your network setup in rc.conf, and how it required tons of special utilities to do things like intelligently connecting to available wifi points? Yuck.
> Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
Funny thing. For me systemd has turned that around. I had no idea what was going on in my system, but systemd allows me to easily visualize it, control it and optimize it.
systemd may not be the ultimate init system which all Unix/Linux versions will end up using, but I have no doubt a future init-systems will take a queue from all these things which systemd has done well.
Feed "systemd-analyze dot" to Graphviz and you get a dependency graph of the current boot.
Also try the other options to systemd-analyze, such as "critical-chain", as well as systemd-cgls to get a view of how the currently running processes relate to specific service files.
Together it should give you a view of what gets executed when (to the fraction of a second) and why.
They have / had an explanation about what needs to be done on their home page. Their news bulletins and their wiki are as important as the distribution itself.
Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
For me, systemd on Arch reduced my boot time from 45s or so to pretty-much-instant-on. Which is pretty damn nice for a distro where one tends to reboot a lot.
> I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf?
rc.conf removal had nothing to do with systemd, I think. And was removed prior.
> What is that killer feature that Arch offers, apart from being rolling release?
The removal of rc.conf was the final step, but they had been dismantling rc.conf piece by piece for years prior, even before systemd was released.
When I first used Arch in 2006, rc.conf held a lot of configuration. From what I understand, it held even more configuration options prior to that. Since that time and until the removal of rc.conf, there was a steady removal of features from rc.conf.
See this prior NH submission [1], and inthe G+ post he mentions fairly early on why it's important to be very quick in the boot process, and how DHCP figures into that. (TL;DR using VM containers that can normally boot within 100 ms, getting the DHCP server to respond within 50 ms means on-demand container spin-up for a specific request is possible)
> What is that killer feature that Arch offers, apart from being rolling release?
Apart from that its pacman, just sick of the apt-get madness.
And generally having far less default crap on you system.
Arch's killer feature, in my mind, is the Arch User Repository[1]. If the package isn't included in Arch's binary repos, the "yaourt" command will build the package (often from git) via a user-contributed script. You can set the make options to Gentoo's suggested -march for your CPU, and build really optimized packages. I'm experiencing <5 second boot times, lower RAM usage, and snappier WINE/WineASIO performance.
Before installing Arch, I was a die-hard Kubuntu/KXstudio[2] user. Now I have the ability to build all the KXstudio packages from git (Cadence, Carla, and Claudia make JACK the greatest thing ever), without all the Ubuntu/Debian cruft underneath.
Another benefit (post-snowden) is that Arch is not an incorporated entity in any of the "Five Eyes" countries. Julian Assange has come out to publicly state knowledge of intentional flaws being added to both Open Source/Free Software projects, and specifically namedrops Debian as compromised. The threat vectors one should analyze are which governments would have access to which corporations. RedHat is a registered corporation in Delaware, USA. Canonical is registered in City of London. If one pays attention to Moxie Marlinspike's convergence demo at DEFCON 19, you can see how it'd be trivial for a government agency such as GCHQ/CCSE/NSA to spoof Canonical's or RedHat's SSL certificates. Gentoo and Arch have no corporate influences, and thus are the only relatively safe Linux distributions left, IMO.
So, AUR, Advanced customization, and potentially increased security are bigger reasons, for me, to switch to Arch than pacman.
'systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries'
So, a collection of lots of single-purpose binaries that work together flies in the face of "do one thing and do it well". I kinda stopped reading at this point, which was sadly quite high up the page.
I think the point is you can't replace each of those binaries with alternatives. The monolithic nature of systemd is not just a function of the raw number of binaries involved.
Those are the external APIs that the various parts of systemd expose to non-systemd applications, the internal APIs are not documented and are subject to change. Basically, you can't just replace part of systemd, you need to write replacements for the whole thing that reimplement all the same APIs in ways that are compatible with it because stuff like Gnome now relies on them.
That's part of the reason why Ubuntu gave up and switched to systemd - a lot of the desktop stuff they shipped relies on logind etc upstream, and it just wouldn't be practical for them to implement their own versions of everything that got Borged by systemd. (Edit: in fact, that page lists logind as something that cannot be independently reimplemented or used separately from systemd.)
Something being (theoretically) possible doesn't mean it's practical.
The attitude of the systemd (And Freedesktop.org folks in general - and please don't give us the usual Lennart cry of "No really, we're NOT the freedesktop.org people!" - despite all of these projects sharing a tightly knit community of people steering them) devs and their treatment of their projects has meant for some you basically do things their way or the highway.[1]
It's already a pain in the ass to strip udev out to keep using it if you've decided to not use systemd. And that's just taking one portion of the system that was promised to be kept easily independent of the rest of the muck, not trying to make other services work within the framework of a systemd system.
As it becomes the standard across all of the major distros, I find it hard to believe that it will become easier to separate systemd parts from one another than it is now, because there becomes even less incentive to do so.
I don't have much of a horse in this race, because I've long since migrated the vast majority of my production systems to FreeBSD and OmniOS, and out of the few that I have that are running linux still, some of them are using systemd. I don't particularly like it, but instead of complaining about it and doing nothing, I've minimized the impact I feel from it.
True, but I think you could say the same thing about git. It's a big bundle of binaries, and there aren't alternatives available that you can swap in and out. And yet, git is seen as the perfect example of the Unix philosophy.
People whip out the Unix philosophy the same way they do every other philosophy: whenever it supports what they already want. I don't think it's a valid argument anymore.
I think that's moving the goal posts a bit. Git is a VCS. You can replace some of git with RCS. More of it with CVS, or all of it with mercurial (modulus a few git corner cases). Git interfaces with email and diff/patch. It can produce text output that can be turned into reports with awk if you're so inclined.
I think arguing that systemd breaks with the unix philosophy is entirely valid -- it's taking what could (does!) arguably exist as separate systems with clean, separating interfaces into one monolithic whole for a somewhat unclear gain.
I wonder how hard it would be to write a compiler/translator from systemd service files to sysv init-scripts?
Given that both systemd and upstart exist, it would seem that it is time for a next generation init. And given that Ubuntu has now accepted systemd, it has critical mass and should be the new standard.
"Doing one thing and doing it well" is a fine guide for system tools, but does not apply to everything - look at the kernel, or Gnome for instance.
"Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions."
I was pretty meh about the whole systemd thing, but having to change userspace when swopping out kernels is a spectacular disadvantage. Imagine having to downgrade your distro whenever you need to test against older kernels --- madness.
This is especially bad with ARM/embedded stuff where one often runs a modern userspace with an older kernel.
In my experiece, upgrading the kernel to a newer one is not a problem. What can happen, though, is that an upgrade of userspace will suddenly require a kernel-feature not present, if you run an ancient board-support-package with a 3.0-kernel or so in 2014! (happened to me with a BSP for a Freescale i.MX6).
So, if you have archlinux tracking the latest and greatest systemd, uptrading userland can make your machine no longer bring up everything (completely). But in my case the kernel is from 2011...
After putting a current arch-linux rootfs[1] on the box[2], it seems to come up, just network and console seems to be misconfigured, but this, I think, I had to fix the last time also. So: indeed the current systemd seems to work on a iMX6 running a 3.0 kernel.
Recent systemd doesn't seem to realize that ethernet and the serial console device are actually there, it's waiting for dev-ttymxc3.device and sys-subsystem-net-devices-eth0.device ... but both are statically compiled in. So there is some issue with kernel 3.0.x.
Upgrading the kernel to a newer one isn't generally a problem, but the changes to cgroups that the systemd and kernel devs are planning to make in the future are not going to be backwards compatible with old userland code.
They'd get much further if they actually came up with a better alternative.
Even if all of there points were objectively true, it doesn't matter when sticking with the old init is so much worse in many ways.
People aren't picking systemd because it's perfect, but because both the mess of init scripts it is replacing, and alternatives like upstart,is seen as worse/too lacking.
EDIT: Btw. this just got me to install systemd on one of our dev/test Debian boxes at work, to start testing it.
it sounds like a lot of the complaints were of the "this makes things easier and smells like it's not the lovechild borne of any arcane hacker and I refuse to read documentation" variety.
Also, I highly recommend reading Lennart Poettering's initial description of systemd on his blog [1]. It lays out the paradigms behind systemd design really well. I think that it is important to understand the problems that systemd is trying to solve in order to evaluate whether it is doing it's job well.
Systemd got a huge boost due the involved from Red Hat. But then most of the distros are adopting it, even Debian and Ubuntu. I don't see a reason but still if you want to stay out of systemd better use Gentoo or other "non" major distro.
Okay, well, while I agree with most of the points they make, there just isn't a viable alternative. I maintain noop Linux (nooplinux.org), it started using OpenRC, but when udev was merged into systemd, things got very complicated, eventually the switch was made. Systemd is very fast, the 'init.d' scripts are way better, udev work very well...I don't mind thinking about moving back away from systemd (because I really do have a love-hate relationship with it), but what am I supposed to go back to? OpenRC/SysV-whatever? Heck no. Upstart? Nope. ...is there even an alternative that makes sense? Because moving back to SysV would be a step back.
"Unix philosophy" seems to be one of those phrases that everyone likes agreeing with because you can use it to either justify or condemn anything you like.
E.g. you could perfectly plausibly make the argument that systemd's return to inetd-style service starting (on-demand and in-parallel through socket activation) is a lot more unix-philosophy-like than the SysVinit way.
Agree, but SysV-init isn't notably unixy. In general, SysV distros raced to embrace and extend away from the mainstream. That created lots of un-unixy subsystems that live on in linux. Quick wave in the direction of three - NFS, wacky IPC systems, SysVinit.
SysVinit is complicated - it wants to be a DSL but is still a shell hack-together. It's inflexible - it's a dependency tracking system, but you can't easily adapt it for userspace launch control, or as a build tool. It doesn't do one thing well. (e.g. doesn't reliably contain a process tree, there are still situations where you want to use pid files or complicated ps greps).
Init is a hard problem. From what I can see all the unix derivatives have made a mess of it. I've had fleeting attempts at writing my own, and I definitely made mess.
In the absence of the good, I reckon the simple becomes the standard. In modern BSDs there's a script called init, it gets called at startup and does nothing for you. I reckon we should judge challengers to init against that.
I can't access that site because it returns 500 right now, but: Can we please get over it?
Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable.
I want to get things done, and managing processes using init scripts and daemonization is pain. Edit: I'v read the cached version now, and this assumption turned out wrong. The authors see a need to replace sysvinit.
The amount of bad and inconsistent init scripts, messy PID file handling, makeshift service wrappers, defective daemonization and logging workarounds is so much worse than having one place that will handle those ever repeated tasks.
I love that in recent years Linux (as in distributions) got an attitude and actively push things forward, without losing compatiblity to older software. Apple introduced launchd and nobody complained. We start to rely docker and all sorts of new approaches to manage our services and nobody complains. But init is somehow regarded as the holy cow noone is supposed to touch although everybody agrees it sucks.
Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.
I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result. How could this get even worse?
If you can't access the site, your toughs about it's current content, look like a you're respectfully trying everybody to disrespect this.
I'm happy about this movement.
In 15 years of sysadmin, I can say that writing init scripts never was a big issue. Maybe for "junior sysadmis" or those that are in the office by their last name.
I respect your opinion, but I'm very afraid of the course that linux is taking regarding system design (dbus, systemd, etc) and I resonate with that page content.
>No newbie sysadmin should touch init scripts because they can't handle it.
There's a lot of things newbie sysadmins are going to be bad at. I wouldn't expect them to come in and architect an infrastructure that will be handling millions of events per second, either. Nor would I expect them to be able to perform a deep dive and become performance engineers.
But sysvinit doesn't have to be the answer. I'm an Illumos guy. The SMF implementation is excellent, moves away from init scripts, and still doesn't throw the baby out with the bathwater like systemd does.
If I was interested in giving up control for the sake of reducing complexity, I'd go back to being a Windows sysadmin so I can click next on wizards and run dcpromo all day.
You can do that with systemd too -- service files are still just ordinary files; they're just "10 lines of info that matters" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate" :P
More like "10 lines of info that matters + I don't know/no reason to look at that" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate"
Saying that systemd service files are complicated because you need to take systemd's internals into account is like saying sysv init scripts are complicated because you need to look at the source code to "cat" and "grep"; ie, no :P
In 20 years of managing Linux systems, I can probably count on one hand the time I saw an init script that was written properly unless it was provided by the distro maintainers (and often not then either). That is, it included all the expected options for the service, it correctly handled pid files for daemons that for whatever reason doesn't do it themselves, it handled reload's gracefully, and so on.
Good riddance to init files.
If these people want to keep people from using systemd, they need to come up with a better alternative.
I don't see init scripts as an argument for writing journal (no more plaintext logfiles), integrating udev, replacing cron, writing their own login manager or handling power management (among other things).
The argument of "do one thing well" might be 20 years old, but no one is holding progress back -- rather raising voices against doing so by aggressively removing choice from the agenda with it's current implementation.
This is all stuff that needs to be taken care of, on every system. So I'm happy that systemd handles the basics in a sensible way.
Why do I as a sysadmin need the choice here? Everything I need is covered by systemd, and in a less painful and more consistent way.
For example, I really do like how systemd-journald takes care of logging, although I don't know why it's not using plaintext log files internally. journald gives me the choice to not log to disk at all, which is nice on embedded systems and my notebook SSD. If i wanted to have logs the old way, i'd just attach a syslogd on journald's socket. With systemd and journald I can have my services log to stderr and everything just works.
I don't have to:
* Log to stderr if my service can't start for some reason
* THEN daemonize (which is a pain to do in node.js and python, and not possible in golang)
* Then switch logging to syslog or my own logfile(s)
* Think about logfile rotation
* use supervisor or monit to make sure my services stay up
Sure, it needs to be taken care of and the creator of that page recognize that when they say "We do recognize the need for a new init system in the 21st century".
Systemd is trying to do TOO MUCH, instead of being a part of a larger system it's trying to become the system. Ad I don't like it, because I don't like tight coupling.
PS: as an alternative you could use a tmpfs to move /var/log (and other log directories) to RAM on an SSD system. Far less configuration required, in my experience. And it works with every *nix out there.
That is a terrible alternative. It is a colossal pain chasing down processes which are still doing open-ended logging into /var/log on a RAM-only system, or guessing which ones may or may not be properly rotating their log files.
The OP is right: some stuff is so essential it should be centralized. Whether systemd is the right way to do that I don't know, but it certainly seems to the compromise we'll live with in the near future. Just as SysV was in the past.
I know you didn't get the chance to read this, but it specifically says:
Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.
And I don't think that's an invalid point. I totally agree that a better init system is desirable, but I've also personally really struggled to understand why systemd is a good approach – it does seem, from someone who's not that close to the issue, that it's an extremely complex and monolithic approach to the problem.
I don't see a boycott happening. Not unless someone steps in to write an alternative init system, which solves some of the issues openrc and systemd solve, but without systemd's baggage.
taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective)
on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. let me bring a few examples:
> To make this work we'd need a patch, as nobody of us tests this.
There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry.
In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves.
edit: some say openrc is the one. here's a comparison:
OpenRC is better than sysvinit, but still isn't the best. However in terms of technology, systemd is the best init system available. The main problems are the developer attitudes and architectural decisions they've made (big blob, work with me or nothing).
runit (from daemontools) might not start things up in parallel, but it's a whole lot simpler and reliable. Phusion uses it instead of upstart in their base docker VM.
Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.
I concur, runit absolutely rocks. Haven't tried systemd yet, I wonder if the two play nice together (if they don't, it won't be runits' fault, that's for sure).
From your other comments I can tell you're a seasoned daemontools user, so let me just put in a quick plug for daemontools-encore [1]. Like runit, daemontools-encore can now run services in separate process groups with setsid(1). Why is this so darn important? Well, under classic daemontools a ./run file with a pipeline in it -- or really anything that forked -- would spin off orphans every time you did `svc -t|-k`. Very bad stuff to deal with in a production environment.
Yup, it's one of those annoying things that makes run scripts more complicated. I rewrote phusion's runit setuser helper in Go because it didn't set all the right env vars.
Huh, looks pretty similar to envuidgid(8) from daemontools. [1]
Another plug for daemontools-encore (last one I promise). The setuidgid(8) program in classic daemontools doesn't set supplementary groups, and a lot of people I know just end up just using sudo in their run files. If you use daemontools-encore though, you can just use `setuidgid -s` instead.
PS. Really, daemontools-encore should imo be called daemontools 1.x, but you know how djb feels about forks of his projects...
The problem as per the Phusion blog article is that the runit and possibly daemontools equivalent commands don't set all env vars: HOME, USER, GID & UID, it only calls setgid() & setuid() IIRC. (envuidgid only sets UID and GID[0]) This causes breakage for lots of apps that end up inheriting root's env instead. :(
Here's the go version I wrote, so there's no need for dep on Python/Ruby/etc on the target system:
setuser USERNAME COMMAND [args...]
# how to build it
go get github.com/steakknife/my_init/setuser
go build github.com/steakknife/my_init/setuser
# creates setuser exe here
you serious? criticizing systemd by promoting a totally new and un-tested software written by a single (for-profit) company.
> Also a lot of enterprise shops use daemontools and runit
provably not true. most enterprise shops run RHEL/CentOS which, to keep support contracts, runs sysvinit or in RHEL/CentOS 6.x ran Upstart. RHEL/CentOS 7 uses systemd and is not going to look back. Don't forget, the "serious" distros have used sysvinit for a very long time. Then they tried out Canonical's Upstart for a bit and decided it was not a step forward, but rather a step to the side. Now they have landed on systemd for very good reasons.
No, sorry, but you don't know what you're talking about.
daemontools is battled tested. We used it at Stanford on thousands of boxes. I used at a lot of shops, one in SF for example had 40k boxes (CentOS) and 6 ops staff, deployed via CFEngine. Heroku uses daemontools. On and on. Daemontools is mostly used when there is no desire/time to replace the existing init completely.
runit also scales amazingly well, even though it's more work to deploy.
Upstart is too unpredictable (flapping) and sysvinit doesn't do supervising very well, which is why important services are deployed with daemontools/runit.
Runit is great as a tool to manage your own daemons. But as a general init system for distributions? Not so much. Just take a look at the /sbin/my_init system that we wrote for baseimage-docker and what kind of functionality it adds on top of Runit, to give you an idea of why Runit by itself is not enough. Runit also performs no dependency management (i.e. starting one service before another) so it's quite painful in certain situations. For example, if you have a background queue daemon that depends on PostgreSQL, then you have to manually make sure that the daemon is not started until PostgreSQL is available. Otherwise you get tons of useless error messages as your daemon keeps getting restarted.
waitport [-u] port [timeout (float)] # -u = UDP instead of TCP
go get github.com/steakknife/my_init/waitport
go build github.com/steakknife/my_init/waitport
# creates waitport bin here
> on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design.
Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.
Linux distros have gotten worse and worse and worse over the years. (So has Windows.) Every 3 years the old way of handling configurations is thrown out and a new one put in place.
That said, I don't know enough to say whether systemd is fixing this problem or if it is contributing to this problem (which it could do even while claiming to fix the problem).
Making init better is a good thing. Breaking working systems is a bad thing. Making gnome not work on *BSD is a terrible thing, not just on a theoretical level but also on a practical one.
Linux itself would have been impossible if the systemd attitude had prevailed among older unix. Linux-only software is the open source community shooting itself in the foot. Systemd will break the community, which will be worse for everyone, linux users included.
This is the free market deciding that non-Linux unixes aren't worth anyone's time. If you believe in the free market, you should either stop complaining and get on the winning team, or hole up in BSD-land rewriting Linux software until you have a plurality market share.
Demanding that open-source developers donate their time to support your particular OS is just leech behavior. Mandating "support equality" is a step in the wrong direction. Open source became great by being free; let's not take that away.
This isn't an argument for systemd at all; it's an argument against supporting any OS with more than one user.
If your OS doesn't matter enough to demand support, it's well within my rights as a developer to ignore you and your users entirely. Cowtowing to a hoard of complaining users is weak behavior.
> This is the free market deciding that non-Linux unixes aren't worth anyone's time. If you believe in the free market, you should either stop complaining and get on the winning team, or hole up in BSD-land rewriting Linux software until you have a plurality market share.
If you believe that then why use Linux at all, when windows' market share is so much bigger? And I thought boycotts were supposed to be the free-market way of changing company policy.
> Demanding that open-source developers donate their time to support your particular OS is just leech behavior. Mandating "support equality" is a step in the wrong direction.
Not supporting *BSD themselves is one thing, but systemd explicitly refuses patches to make it more portable.
>And I thought boycotts were supposed to be the free-market way of changing company policy.
Boycotts are what shrill activists on the losing side engage with. The free-market way to change company policy is to start a new company and make new policy. Doing otherwise is just trying to leech off of the success of other, stronger people.
>Not supporting *BSD themselves is one thing, but systemd explicitly refuses patches to make it more portable.
This is exactly what OpenBSD is doing with LibreSSL, so excuse me if I don't listen to the pot calling the kettle black.
The fact of the matter is that Linux won. Systemd won. Alternatives had every chance to make themselves successful, but they lost, and they have nobody to blame for that but themselves.
"Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done..."
The Unix philosophy (loose coupling of specialized pieces) is what permits you to get things done. It is the foundational theory behind the most successful architecture on the planet.
systemd is doing things the Windows way -- monolithic, tightly coupled systems wherein, using Occam's Razor, the explanation for some of the coupling has to go into the realm of the nontechnical.
Those of us who have to manage and create large complex systems sort of scratch our heads at the idea that desktop systems booting faster is an important goal deserving of all this mess. Linux on the desktop has always been terrible and will always be terrible, and getting to it a few seconds faster is not helping you.
Windows has historically sported better system integration than Unix, with system components of greater granularity and flexibility than Unix has historically provided thanks to the power of COM interfaces. If the tightly coupled Windows way provides a better solution, then maybe we should build things the Windows way.
nothing that you said is actually true. There are probably 10,000 Unix systems for every windows system now, and all of them support far greater granularity and flexibility than any windows device has ever offered.
> Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products [sic], and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.
This statement is so utter in faultiness, I don't even know where to begin. In the first statement, you say “Regardless of the truth of it; this axiom X is true.”, and introduce a logical paradox, similar to the sentence “This sentence is not true.”[1]. Consequently, you call Mac OS X, FreeBSD and alike niche. The former is the second most popular commercial desktop OS, and the latter is incorporated into the former and also is the OS that powers PlayStation 4[2][3].
You say that “init systems need not be compatible”, and I say yes. Also, OS interfaces need not be compatible. Implementations of C library need not be compatible either, nor implementations of C themselves. Why did the size of a byte were standardised anyway[4]?
> I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result.
You wouldn't have to if there were a standard initialisation interface, would you?
> Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain.
You want to get things done today; I'd guess you'd also like to keep thing happening 10 years later, when Linux is no longer as popular (Software come and go, no-one can guarantee that, say, illumos[5] will not become more popular than Linux in 10 years). Would you rather run around porting your init scripts to the new OS a cloud provider fancies, which your boss fancies, or write new bugs (which some refer to as features)? Would you rather wait for the mainstream repos of your favourite projects to catch up, or just deploy the program and enhance the experience? Would you rather read pages of documentation for your new incompatible init system, or skim the frontpage of HN?
> We start to rely docker and all sorts of new approaches to manage our services and nobody complains.
Well, Docker is a containment and distribution solution and programs need not be modified nor need to have around Docker to run. It is reminiscent of a FreeBSD jail or a plain old VM.
> Apple introduced launchd and nobody complained.
Just compare the source trees, you'll be enlightened[6][7].
> You wouldn't have to if there were a standard initialisation interface, would you?
My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.
With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.
About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible.
I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.
So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.
And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.
> [And] if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.
It is not ten lines of service config being hard, though, it is grokking a new, ad hoc tech, which is necessary to get the most out of it. I have not a rage against systemd in itself; it is too low level for me to care about, process management that is, yet I'd support, to the last drop of my blood, a standard to cover initialisation. If I have to write an init script/config/whatever one day, I'd rather use a standard format that I can get to work on any system, than an ad hoc, OS-specific technology that I have to re-learn every time I switch operating systems.
You seem to overlook the importance of a process hat supervises other processes. I reckon that it should be so stable, one shouldn't notice it. That is possible if and only if the thing is tested and implemented according to a standard throughout long times.
> Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.
I think it's a shame most of the original page comes off as backwards thinking, Unix nostalgia and FUD like claims.
Because this one thing is actually quite important and something we should care about.
You can claim that Linux is now Unix and everything else is just niches. Great. Like Hurd. Clearly a play-thing. No point being portable enough to work there.
However back in the days, Unix was the real thing and Minix/Linux was just a toy itself. But hadn't software initially been portable, Linux could never have risen to what it is today.
When we are making an init-system with Linux kernel-dependencies, and making other core platform services like DEs dependent on this init-system again, we are tightening the bonds beyond what's useful, effectively hindering other platforms from ever gaining mass adaptation, even if they should otherwise deserve it.
SO while I appreciate systemd in general there are aspects of this development I indeed thinks deserves some more and warranted criticism.
Actually it's not like this. On FOSS when there is no manpower distros need to make a choice: supporting the software themselves or pick the maintained solution. So when upstart developed slowed down, by other words Canonical pulled resources from it, it was when they made the decision to switch to systemd.
Also the cost of maintain it and adapt applications who are tied to systemd is much more larger than adopting syetemd.
The only viable solution i'm seeing right now is: Use a mainstream distro with systemd or switch to other one which maintains their own init system like Slackware or Gentoo.
This is the "TempleOS impulse". The feeling of disgust with byzantine complexity, driving an impulse to start clean and chase the money changers out of the temple
For Linux to keep evolving, part of evolution is mutation, the strong will flourish while the weak will die.
Regardless of what init system is right or wrong, the beauty of the Linux ecosystem is we can afford for different distributions each to make different decisions.
Systemd seems functionally better than both sysvinit and upstart and it certainly doesn't seem to be the root of all evil like this article makes out.
I don't believe that everyone boycotting systemd over what's currently out there will aid linux in any way.
When everything will use systemd (because all the "core system" is starting to depend on it, wayland included) how do you evolve out of it?
Rewrite the entire lower level of your system AGAIN?
That does not help evolving rapidly, in my opinion.
No, and I'm sorry I was not able to explain that properly. :)
We should not (re)write a lower level where all the components are so coupled we will be unable to change one of them with a better alternative without changing the rest.
> an abhorrent and violent slap in the face to the Unix philosophy
I'm tired of all this UNIX philosophy crap. I have been using Systemd for more than a year now, on Archlinux, and it has been a delightful experience.
It works out of the box and it gets a lot of things right.
Journald is quick & easy to use and a real help in finding problems. No more searching around in log files and grepping.
Dependencies between services are handled by the init.
Services start with maximum parallelism.
Writing .service files is really easy.
It simply has better UX than any other init system, and it's supported by a lot of distros.
This means standardization and progress. No more developer time wasted on sysvinit scripts.
The posted link is the same FUD that I have been reading for the last year on various forums. Even if systemd can be a single point of failure, it's still way more stable than anything we have used before.
For me it always feels like people who are bashing on systemd never actually used it. I was very concerned about systemd for long time. And nowadays I use it on all my machines/servers. And it just makes my life so much easier. I'm happy. I like it. I can agree with lot of points on this website. But still systemd makes my happy. So sorry, but no.
For 99% of uses, esp desktop, laptop, embedded... it's great.
For that tiny percent of use cases where services can do all kinds of crazy things and there needs to be extra control, other things like supervisor, foreman_god, daemontools/runit come into play. There are use-cases not many people have to deal with or even exposed to, yet are important considering the impact (say downing a major service like Gmail).
We just install daemontools on all of our servers for our own stuff and let the system packages use whatevers the default in the distro, they seem to live happily together.
I suspect that one issue with systemd is that it aims to solve very real problem, but they are problems that not many noticed. Most of the stuff that's highlighted as benefits of systemd are things I never experienced, either I don't thing advanced enough or the issue has already been addressed by the distro.
Most of us are just going have some daemon/process that we want to start at boot and for that purpose systemd is going to look like massive overkill and overly complicated. That might be mostly a documentation issue, systemd could benefit for a "So you want to start at process" guide.
I don't know much about systemd, so I can't say either way.
So long as I can still get syslog style plain text logs, then I have no objections. Unix and text log parsing is unparalleled. If simple text log parsing and manipulation is removed (all binary with only xml or json), then I'd be very opposed to systemd.
237 comments
[ 4.8 ms ] story [ 265 ms ] threadI wish the owner of that website would would make a better alternative instead of complaining.
There's nothing wrong with saying "I like Linux, but it's becoming Lennartix and I'm concerned."
Already the reason 1. is crippling Linux and what it stands for. All points combined mean that if you include this in distribution, that distribution will stagnate and die.
That said, a lot of systemd seems like a really stupid idea to me, e.g. binary logs, the massively increased SPOF size, and the "do everything" mentality. Unfortunately, I don't know of any distros that aren't using it now (edit: I didn't even realise Slackware was still a thing...), and upstart is even more of a joke than systemd.
[1] http://www.freedesktop.org/wiki/Software/systemd/journal-fil...
tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.
All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
Actually, they won't. Because journald has the relevant functionality built-in -- that is, it can automatically stream out the logs in any format you choose, including ones understood by rsyslogd, and if you really just don't like journald, you can just turn off it's storage and turn it into nothing but a shim.
So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo.
> All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that.
Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information.
Regarding the last point, here's an example of an entry from journalctl -o json-pretty:
It sort of okay when you only have one system that does binary logs, but what if you have 5 or 10, each with their own log format and little tool that I need to pipe the log file through?
The binary logs also assumes that you actually know where stuff is or that you're not going to look across multiple systems in one go. If you're large enough you'll have logstash/splunk or something similar where you have already de-binarized the log and this become less of an issue.
But for may of us doing a "grep <something> 2014-04-*.log" is something that's just natural and we come a bit hostile if you're trying to take that away.
That being said I think systemd might have a way of just giving you the log in plaintext.
Also, systemd writes syslog style plaintext messages to an IPC socket at /run/systemd/journal/syslog if needed for compatibility.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Summary:
Dmd is the gnu daemon managing daemons.
Im planning at least to provide more documentation, when I learn guix and dmd more.
I'm a huge fan of Lisp-based languages, but this thing actually wants people to use Lisp for creating service files!
http://www.gnu.org/software/dmd/manual/dmd.html#Service-Exam...
Not even data-based lisp like Clojure's data format (the one that Light Table uses for its configs, forget the name), but full-on lisp!. That would be a maintenance nightmare for sys admins.
Not to mention that it seems rather sparse in basic features... I couldn't find any example in the manual for setting users & groups or permissions. These are fundamental.
I love the fact that the configuration is written in Guile. Data is code and code is data after all. I think you're exaggerating the maintenance nightmare. In fact, the Guix project has already proven that newcomers who don't really know s-expression style syntax can write software packages.
The only way to actually manage such a DSL/Schema is to provide a way to "break out" of it into a general purpose language - that's what systemd does by allowing you to run shell scripts in the case you're not using a "standard" service, and it's also what the Nix expression language does in order to build software.
It's far easier to just provide a fully capable language up front - and abstract the common patterns into functions or macros to simplify the usage for users. sysv has worked well with just shell scripts for years, despite it being a sub-standard general purpose language - although various hacks like the LSB init headers have been added to provide some kind of structure to them - a problem that will be better solved with records in Guile.
As for maintenance, I see it as a big plus - with a language like Guile you have access to a useful REPL and debugger - no need to roll your own debugging interface or inspect log files. On top of that, having a dynamic language makes it easier to develop and test patches for new requirements - you're not forced to recompile and restart your DSL.
0: udev did that. They merged udev in. Now systemd does it. I'd rather see them play nice by communicating with other projects than controlling everything on their own.
1: Apart from internal watchdog, the features he listed are also available in upstart. (others are not, but his list is actually common)
3: This is a strange claim when talking about an init system that effectively starts managing devices.
6: Not sure why it's on the good things list - it already happened before for rc/init/upstart. It's inevitable rather than new awesome - we'll all have to rewrite the configs once again.
8: Why is that part of systemd? Ubuntu was happily running with it being a separate daemon. If it doesn't depend on systemd why is it included (same for udev really). Convenience for developers is not a great answer here.
There seems to be a lot of exaggerated claims going both ways - at least that shows not everyone is happy about the change. Hopefully the next project that replaces init will be what many claim systemd is right now...
I'm not sure why the same maintainer matters for merging. Take openstack as a counter-example. It's mostly the same pool of contributors working on a number of related projects. Not only have they been split into components (nova, nova-volume, nova-network -> nova, cinder, quantum projects), common functionality has been split into separate library projects of their own (oslo-messaging, oslo-logging, etc.) with their own releases, versioning, leadership. This is what I really like and it's exactly the opposite of what systemd is doing (merging device, network, logging, etc. into one system).
If systemd is modular (doesn't require logind) and logind is standalone (requiring only systemd as a library) - what's the point of bundling them. (apart from making it harder for others to use) Systemd owns too much at the same time and I believe it's going to lead to problems in the future.
"I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA
If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :)"
The CLA is absolutely why systemd exists. systemd didn't fork because there was no benefit to anyone in sharing code -- Upstart wouldn't take their patches. There are technical differences, but those could have been handled in code (like Scott says) if the CLA hadn't existed.
1 https://plus.google.com/+KaySievers/posts/C3chC26khpq
This does not make sense to me. They could fork it if it was good enough. If they started from scratch, then CLA wasn't the main issue. It's like "the corner store didn't have the milk I like today so I had to start my own farm".
If there was no CLA, the folks who went on to develop systemd could have decided that the benefits of collaborating with an existing project were greater than the benefits of writing systemd from scratch. And everyone involved seems to agree that that's what would have happened. Yes, as a purely technical matter, the systemd people decided starting from scratch was better than forking Upstart. But the reason it was a purely technical decision was their refusal to sign the CLA, which meant the ONLY considerations were technical. But there are other considerations that could have swung the decision the other way if not for the CLA.
Which certainly means he has the right to merge udev in, but it doesn't necessarily make it a nice thing to do for the rest of the community.
Those that have become dependent on udev without believing they'd be hitching their cart to a horse that replaces the init system, cron, at, syslog, etc. now have to go through the process of building systemd to rip udev out, and keep their fingers crossed that it doesn't get harder (or outright impossible).
Lots of projects in the open source community get split up as they get bigger. One of the other commenters on here mentions all of the openstack stuff, which I think is a great example.
From my anecdotal experience in watching the open source community over the last 14 years is that most people, when working on multiple projects, keep them as multiple projects, unless they are /really/ duplicating functionality, and thus, effort. Even then, they might not merge them. See: All of the work Brendan Gregg does for performance engineering tools. He's constantly writing small patches to improve KTap, Systemtap, Sysdig, DTrace linux ports, etc. Despite the fact they're all competing projects. Granted, he's not in charge of any of them, and I can't read his mind, but would someone who likes merging projects together sit there and spend so much time constantly improving projects that are competing with each other? I doubt it.
In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?
What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine).
http://www.skarnet.org/software/s6/index.html
I've been using s6 to manage a few things, and some features I like are:
- allow a group to manage (stop/restart) certain processes using Unix file permissions
- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
http://skarnet.org/software/s6/why.html
The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.
I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false.
dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd).
systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMORIt is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition.
systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite.
Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
Beside that, I recommend you'd take a look at http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... and possibly http://www.freedesktop.org/software/systemd/man/.
I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.
> 0) That's not the init systems job.
For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.
From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable.
Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.
No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one.
Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.
That nevertheless doesn't have anything to do with hotplugging devices, nor does it suggest that we should create an init system which handles dhcp, qr codes, and, no shit, takes core files and jams them into its binary log.
See other replies.
I do (rarely) install Linux on some new PC but I think I stopped installing Arch after this changes. I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf? What is that killer feature that Arch offers, apart from being rolling release?
Anecdotal evidence can be dismissed by anecdotal evidence -- A variation of Hitches' razor
Switching to systemd broke _my_ entire Arch _experience_. Before systemd I knew exactly what gets executed, when and why -- which is exact reason why I switched to Arch many years ago. I don't know the same thing after systemd introduction.
> $ ls -al /etc/systemd/system
and look at its contents. It is not that hard. It changed everyone's experience. Some people just hate change. Others deal with it.
While it did make desktop / laptop users experience a little bit more complicated, from what I have read it makes things much easier on the sysadmins who are working with lots of daemons on the servers.
As a general point for everyone: Just because it's _also_ an init system doesn't mean it's not allowed to provide the binaries for doing a whole lot of other stuff. :)
Why can't we have an independent organisation that defines a spec for all the relevant APIs and tools for managing a system, and systemd just be one implementation of that spec? Actually, it could be a suite of specs, so people could pick and choose which ones solve their problems, and build alternatives for others.
> [...] by the same people, with the same ideas, and the same gatekeepers [...]
Isn't this exactly what made the Linux Kernel great? A consistent vision.
I agree with you on a few points though, the systemd team should be more cooperative and start being conservative on the API changes. If the API is defined clearly, it shouldn't be hard to make proper replacements for parts of it.
I disagree strongly that there should be an independent Organisation to define that spec, because that would quickly be overrun by bikeshedding and all the other problems stemming from design by comittee. Very often in the Open Source world, specs have been defined by the first people arriving at the scene, so to speak. It all works over dbus, no? That is a fairly simple protocol to implement. I think it's an elegant IPC solution.
Anyway. cheers!
Sure, but even today, the Linux kernel has competition. I can run most things on Windows or OSX or FreeBSD or Solaris, even if the technical details are different. I worry about a monoculture forming around systemd, as seems to be happening now; I can't find a modern distro that uses anything else (aside from Gentoo, which I can't take seriously for production work), and it's starting to be assumed that systemd is the only init system that anybody will use.
You can still use Windows, OSX or FreeBSD.
Funny thing. For me systemd has turned that around. I had no idea what was going on in my system, but systemd allows me to easily visualize it, control it and optimize it.
systemd may not be the ultimate init system which all Unix/Linux versions will end up using, but I have no doubt a future init-systems will take a queue from all these things which systemd has done well.
Also try the other options to systemd-analyze, such as "critical-chain", as well as systemd-cgls to get a view of how the currently running processes relate to specific service files.
Together it should give you a view of what gets executed when (to the fraction of a second) and why.
Maybe on Arch this is simpler, on Fedora systemd-analyze dot produces a nightmare that no human mind can navigate.
> -- Try a shell pipeline like 'systemd-analyze dot | dot -Tsvg > systemd.svg'!
EDIT: there are 1101 edges in the graph produced on my machine.
I don't know if it didn't break for the majority but for me it certainly did on many installations.
Like being good solid rolling release distro is not good enough? Frankly I prefer my distros to be free of any "killer features".
That may not sound like much, but it's pretty awesome. I use it as a reference on a few things even when dealing with other Linux distros.
e.g. The page on SSH basically starts with how to restrict users who can log in and disabling root. https://wiki.archlinux.org/index.php/Secure_Shell
Haven't used Arch in a while - not dealt with a non-company Linux box for a while. But it remains my go-to Linux (for development purposes) for good reasons.
> I mean what's the point installing Arch if there is no very elegant and beautiful rc.conf?
rc.conf removal had nothing to do with systemd, I think. And was removed prior.
> What is that killer feature that Arch offers, apart from being rolling release?
Vanilla upstream packages.
When I first used Arch in 2006, rc.conf held a lot of configuration. From what I understand, it held even more configuration options prior to that. Since that time and until the removal of rc.conf, there was a steady removal of features from rc.conf.
I'd be interested to know if the systemd boot process (which can be 2 seconds or quicker) has enough advantages to make the other changes worth it.
[1]: https://news.ycombinator.com/item?id=7510660
[1] https://github.com/icy/pacapt
Before installing Arch, I was a die-hard Kubuntu/KXstudio[2] user. Now I have the ability to build all the KXstudio packages from git (Cadence, Carla, and Claudia make JACK the greatest thing ever), without all the Ubuntu/Debian cruft underneath.
Another benefit (post-snowden) is that Arch is not an incorporated entity in any of the "Five Eyes" countries. Julian Assange has come out to publicly state knowledge of intentional flaws being added to both Open Source/Free Software projects, and specifically namedrops Debian as compromised. The threat vectors one should analyze are which governments would have access to which corporations. RedHat is a registered corporation in Delaware, USA. Canonical is registered in City of London. If one pays attention to Moxie Marlinspike's convergence demo at DEFCON 19, you can see how it'd be trivial for a government agency such as GCHQ/CCSE/NSA to spoof Canonical's or RedHat's SSL certificates. Gentoo and Arch have no corporate influences, and thus are the only relatively safe Linux distributions left, IMO.
So, AUR, Advanced customization, and potentially increased security are bigger reasons, for me, to switch to Arch than pacman.
1. http://aur.archlinux.org
2. http://kxstudio.sourceforge.net
So, a collection of lots of single-purpose binaries that work together flies in the face of "do one thing and do it well". I kinda stopped reading at this point, which was sadly quite high up the page.
Is there any reason why you couldn't do so?
Found this chart: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... Note the columns "Reimplementable Independently" and "Known Other Implementations"
That's part of the reason why Ubuntu gave up and switched to systemd - a lot of the desktop stuff they shipped relies on logind etc upstream, and it just wouldn't be practical for them to implement their own versions of everything that got Borged by systemd. (Edit: in fact, that page lists logind as something that cannot be independently reimplemented or used separately from systemd.)
The attitude of the systemd (And Freedesktop.org folks in general - and please don't give us the usual Lennart cry of "No really, we're NOT the freedesktop.org people!" - despite all of these projects sharing a tightly knit community of people steering them) devs and their treatment of their projects has meant for some you basically do things their way or the highway.[1]
It's already a pain in the ass to strip udev out to keep using it if you've decided to not use systemd. And that's just taking one portion of the system that was promised to be kept easily independent of the rest of the muck, not trying to make other services work within the framework of a systemd system.
As it becomes the standard across all of the major distros, I find it hard to believe that it will become easier to separate systemd parts from one another than it is now, because there becomes even less incentive to do so.
I don't have much of a horse in this race, because I've long since migrated the vast majority of my production systems to FreeBSD and OmniOS, and out of the few that I have that are running linux still, some of them are using systemd. I don't particularly like it, but instead of complaining about it and doing nothing, I've minimized the impact I feel from it.
[1] https://news.ycombinator.com/item?id=7534583
People whip out the Unix philosophy the same way they do every other philosophy: whenever it supports what they already want. I don't think it's a valid argument anymore.
I think arguing that systemd breaks with the unix philosophy is entirely valid -- it's taking what could (does!) arguably exist as separate systems with clean, separating interfaces into one monolithic whole for a somewhat unclear gain.
I wonder how hard it would be to write a compiler/translator from systemd service files to sysv init-scripts?
I can understand suggesting to migrate to BSD, but Plan 9? Seriously?
And what's the purpose of the "Open Source Tea Party" picture? This surely is not the only picture of Lennart in existence.
"Doing one thing and doing it well" is a fine guide for system tools, but does not apply to everything - look at the kernel, or Gnome for instance.
"Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions."
I was pretty meh about the whole systemd thing, but having to change userspace when swopping out kernels is a spectacular disadvantage. Imagine having to downgrade your distro whenever you need to test against older kernels --- madness.
This is especially bad with ARM/embedded stuff where one often runs a modern userspace with an older kernel.
So, if you have archlinux tracking the latest and greatest systemd, uptrading userland can make your machine no longer bring up everything (completely). But in my case the kernel is from 2011...
Can you give an example of the "no longer bring up everything (completely)"?
[1] ArchLinuxARM-imx6-latest.tar.gz from http://archlinuxarm.org/developers/downloads
[2] Phytec PhyFlex i.MX6 http://www.phytec.de/de/produkte/system-on-modules/produktde...
Recent systemd doesn't seem to realize that ethernet and the serial console device are actually there, it's waiting for dev-ttymxc3.device and sys-subsystem-net-devices-eth0.device ... but both are statically compiled in. So there is some issue with kernel 3.0.x.
http://cgit.freedesktop.org/systemd/systemd/tree/README#n39
Even if all of there points were objectively true, it doesn't matter when sticking with the old init is so much worse in many ways.
People aren't picking systemd because it's perfect, but because both the mess of init scripts it is replacing, and alternatives like upstart,is seen as worse/too lacking.
EDIT: Btw. this just got me to install systemd on one of our dev/test Debian boxes at work, to start testing it.
> 2. systemd's journal files (handled by journald) are stored in a complicated binary format.
Mr Poettering tackles the myth that configuration files are binary (they are very obviously not).
That said, I am not sure how to get the journaling data in an Upstart system, nor in a sysvinit one.
[1] http://0pointer.de/blog/projects/systemd.html
(the site is unreachable at the moment).
I got past that by using eudev with OpenRC on Gentoo.
E.g. you could perfectly plausibly make the argument that systemd's return to inetd-style service starting (on-demand and in-parallel through socket activation) is a lot more unix-philosophy-like than the SysVinit way.
SysVinit is complicated - it wants to be a DSL but is still a shell hack-together. It's inflexible - it's a dependency tracking system, but you can't easily adapt it for userspace launch control, or as a build tool. It doesn't do one thing well. (e.g. doesn't reliably contain a process tree, there are still situations where you want to use pid files or complicated ps greps).
Init is a hard problem. From what I can see all the unix derivatives have made a mess of it. I've had fleeting attempts at writing my own, and I definitely made mess.
In the absence of the good, I reckon the simple becomes the standard. In modern BSDs there's a script called init, it gets called at startup and does nothing for you. I reckon we should judge challengers to init against that.
Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain. Edit: I'v read the cached version now, and this assumption turned out wrong. The authors see a need to replace sysvinit.
The amount of bad and inconsistent init scripts, messy PID file handling, makeshift service wrappers, defective daemonization and logging workarounds is so much worse than having one place that will handle those ever repeated tasks.
I love that in recent years Linux (as in distributions) got an attitude and actively push things forward, without losing compatiblity to older software. Apple introduced launchd and nobody complained. We start to rely docker and all sorts of new approaches to manage our services and nobody complains. But init is somehow regarded as the holy cow noone is supposed to touch although everybody agrees it sucks.
Even if it's technically wrong: Unix as a platform is now Linux. Everything else is niche products, and we don't have to use the same init mechanism on Linux/BSD/whatever just because we can.
I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result. How could this get even worse?
I'm happy about this movement.
In 15 years of sysadmin, I can say that writing init scripts never was a big issue. Maybe for "junior sysadmis" or those that are in the office by their last name.
I respect your opinion, but I'm very afraid of the course that linux is taking regarding system design (dbus, systemd, etc) and I resonate with that page content.
No newbie sysadmin should touch init scripts because they can't handle it.
Isn't it about damn time we go from overly complex to what makes sense?
“The only way to control chaos and complexity is to give up some of that control”
There's a lot of things newbie sysadmins are going to be bad at. I wouldn't expect them to come in and architect an infrastructure that will be handling millions of events per second, either. Nor would I expect them to be able to perform a deep dive and become performance engineers.
But sysvinit doesn't have to be the answer. I'm an Illumos guy. The SMF implementation is excellent, moves away from init scripts, and still doesn't throw the baby out with the bathwater like systemd does.
If I was interested in giving up control for the sake of reducing complexity, I'd go back to being a Windows sysadmin so I can click next on wizards and run dcpromo all day.
Jr: "I edited some init file."
Sr: "Which one?"
Jr: "I forget."
Sr: "Oh." sorts /etc directory by time "Oh, I see what you changed. That is wrong because of $REASON. You should do $CORRECT_THING instead."
Jr: "Okay, thanks for letting me know."
Sr: "We were all new guys once."
Good riddance to init files.
If these people want to keep people from using systemd, they need to come up with a better alternative.
The argument of "do one thing well" might be 20 years old, but no one is holding progress back -- rather raising voices against doing so by aggressively removing choice from the agenda with it's current implementation.
For example, I really do like how systemd-journald takes care of logging, although I don't know why it's not using plaintext log files internally. journald gives me the choice to not log to disk at all, which is nice on embedded systems and my notebook SSD. If i wanted to have logs the old way, i'd just attach a syslogd on journald's socket. With systemd and journald I can have my services log to stderr and everything just works.
I don't have to: * Log to stderr if my service can't start for some reason * THEN daemonize (which is a pain to do in node.js and python, and not possible in golang) * Then switch logging to syslog or my own logfile(s) * Think about logfile rotation * use supervisor or monit to make sure my services stay up
PS: as an alternative you could use a tmpfs to move /var/log (and other log directories) to RAM on an SSD system. Far less configuration required, in my experience. And it works with every *nix out there.
The OP is right: some stuff is so essential it should be centralized. Whether systemd is the right way to do that I don't know, but it certainly seems to the compromise we'll live with in the near future. Just as SysV was in the past.
Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.
And I don't think that's an invalid point. I totally agree that a better init system is desirable, but I've also personally really struggled to understand why systemd is a good approach – it does seem, from someone who's not that close to the issue, that it's an extremely complex and monolithic approach to the problem.
taking the discussion out of the opinion level to a more factual level(eg. i like the boot speed of my archlinux machine but the whole consolekit(why did we get that to begin with ?)/logind/ridiculousness, logging and service files vs. startx and grep /var/log is annoying to say the least, but as i said subjective)
on a factual level we have ridiculous bugs specifically caused by systemd that take down your system, and the lead developers saying either i don't care or it's by design. let me bring a few examples:
https://bugs.freedesktop.org/show_bug.cgi?id=76935
> That is the expected current behaviour, "debug" can cause "too many" messages to be useful anymore if things are broken.
or this one, systemd segfaulting with cgroups off:
https://bugs.freedesktop.org/show_bug.cgi?id=74589
Lennart:
> To make this work we'd need a patch, as nobody of us tests this.
There were a few other recent ones. When your new init system consistently takes down your operating syste, because of stupid bugs, and the lead developers say we don't care, and even block efforts to fix these issues, you should indeed worry.
https://plus.google.com/111049168280159033135/posts/Kd57G8s1...
In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson commented that that patch would not be merged as it's not clear what problem it solves.
edit: some say openrc is the one. here's a comparison:
https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
I thought OpenRC was that init system? Or what systemd baggage comes with it?
Also a lot of enterprise shops use daemontools and runit, because they just fucking scale.
[1] http://untroubled.org/daemontools-encore/
https://raw.githubusercontent.com/steakknife/my_init/master/...
Another plug for daemontools-encore (last one I promise). The setuidgid(8) program in classic daemontools doesn't set supplementary groups, and a lot of people I know just end up just using sudo in their run files. If you use daemontools-encore though, you can just use `setuidgid -s` instead.
PS. Really, daemontools-encore should imo be called daemontools 1.x, but you know how djb feels about forks of his projects...
[1] http://cr.yp.to/daemontools/envuidgid.html
Here's the go version I wrote, so there's no need for dep on Python/Ruby/etc on the target system:
[0] FR issue submitted as https://github.com/bruceg/daemontools-encore/issues/18you serious? criticizing systemd by promoting a totally new and un-tested software written by a single (for-profit) company.
> Also a lot of enterprise shops use daemontools and runit
provably not true. most enterprise shops run RHEL/CentOS which, to keep support contracts, runs sysvinit or in RHEL/CentOS 6.x ran Upstart. RHEL/CentOS 7 uses systemd and is not going to look back. Don't forget, the "serious" distros have used sysvinit for a very long time. Then they tried out Canonical's Upstart for a bit and decided it was not a step forward, but rather a step to the side. Now they have landed on systemd for very good reasons.
daemontools is battled tested. We used it at Stanford on thousands of boxes. I used at a lot of shops, one in SF for example had 40k boxes (CentOS) and 6 ops staff, deployed via CFEngine. Heroku uses daemontools. On and on. Daemontools is mostly used when there is no desire/time to replace the existing init completely.
runit also scales amazingly well, even though it's more work to deploy.
Upstart is too unpredictable (flapping) and sysvinit doesn't do supervising very well, which is why important services are deployed with daemontools/runit.
Runit is great as a tool to manage your own daemons. But as a general init system for distributions? Not so much. Just take a look at the /sbin/my_init system that we wrote for baseimage-docker and what kind of functionality it adds on top of Runit, to give you an idea of why Runit by itself is not enough. Runit also performs no dependency management (i.e. starting one service before another) so it's quite painful in certain situations. For example, if you have a background queue daemon that depends on PostgreSQL, then you have to manually make sure that the daemon is not started until PostgreSQL is available. Otherwise you get tons of useless error messages as your daemon keeps getting restarted.
A collection of individual tools that can be cherry-picked to solve nitty-gritty problems.
Agreed. This is a big worry. When the lead developers of something this important sound this callous, I start getting concerned.
Linux distros have gotten worse and worse and worse over the years. (So has Windows.) Every 3 years the old way of handling configurations is thrown out and a new one put in place.
That said, I don't know enough to say whether systemd is fixing this problem or if it is contributing to this problem (which it could do even while claiming to fix the problem).
Linux itself would have been impossible if the systemd attitude had prevailed among older unix. Linux-only software is the open source community shooting itself in the foot. Systemd will break the community, which will be worse for everyone, linux users included.
This is the free market deciding that non-Linux unixes aren't worth anyone's time. If you believe in the free market, you should either stop complaining and get on the winning team, or hole up in BSD-land rewriting Linux software until you have a plurality market share.
Demanding that open-source developers donate their time to support your particular OS is just leech behavior. Mandating "support equality" is a step in the wrong direction. Open source became great by being free; let's not take that away.
If your OS doesn't matter enough to demand support, it's well within my rights as a developer to ignore you and your users entirely. Cowtowing to a hoard of complaining users is weak behavior.
If you believe that then why use Linux at all, when windows' market share is so much bigger? And I thought boycotts were supposed to be the free-market way of changing company policy.
> Demanding that open-source developers donate their time to support your particular OS is just leech behavior. Mandating "support equality" is a step in the wrong direction.
Not supporting *BSD themselves is one thing, but systemd explicitly refuses patches to make it more portable.
Boycotts are what shrill activists on the losing side engage with. The free-market way to change company policy is to start a new company and make new policy. Doing otherwise is just trying to leech off of the success of other, stronger people.
>Not supporting *BSD themselves is one thing, but systemd explicitly refuses patches to make it more portable.
This is exactly what OpenBSD is doing with LibreSSL, so excuse me if I don't listen to the pot calling the kettle black.
The fact of the matter is that Linux won. Systemd won. Alternatives had every chance to make themselves successful, but they lost, and they have nobody to blame for that but themselves.
The Unix philosophy (loose coupling of specialized pieces) is what permits you to get things done. It is the foundational theory behind the most successful architecture on the planet.
systemd is doing things the Windows way -- monolithic, tightly coupled systems wherein, using Occam's Razor, the explanation for some of the coupling has to go into the realm of the nontechnical.
Those of us who have to manage and create large complex systems sort of scratch our heads at the idea that desktop systems booting faster is an important goal deserving of all this mess. Linux on the desktop has always been terrible and will always be terrible, and getting to it a few seconds faster is not helping you.
This statement is so utter in faultiness, I don't even know where to begin. In the first statement, you say “Regardless of the truth of it; this axiom X is true.”, and introduce a logical paradox, similar to the sentence “This sentence is not true.”[1]. Consequently, you call Mac OS X, FreeBSD and alike niche. The former is the second most popular commercial desktop OS, and the latter is incorporated into the former and also is the OS that powers PlayStation 4[2][3].
You say that “init systems need not be compatible”, and I say yes. Also, OS interfaces need not be compatible. Implementations of C library need not be compatible either, nor implementations of C themselves. Why did the size of a byte were standardised anyway[4]?
> I have deployed the same software on Debian Linux, RHEL Linux and AIX and basically had to reimplement service management scripts for every platform to have the best possible result.
You wouldn't have to if there were a standard initialisation interface, would you?
> Quoting the "Unix philosophy" as the reason to keep things like they were 20 years ago is laughable. I want to get things done, and managing processes using init scripts and daemonization is pain.
You want to get things done today; I'd guess you'd also like to keep thing happening 10 years later, when Linux is no longer as popular (Software come and go, no-one can guarantee that, say, illumos[5] will not become more popular than Linux in 10 years). Would you rather run around porting your init scripts to the new OS a cloud provider fancies, which your boss fancies, or write new bugs (which some refer to as features)? Would you rather wait for the mainstream repos of your favourite projects to catch up, or just deploy the program and enhance the experience? Would you rather read pages of documentation for your new incompatible init system, or skim the frontpage of HN?
> We start to rely docker and all sorts of new approaches to manage our services and nobody complains.
Well, Docker is a containment and distribution solution and programs need not be modified nor need to have around Docker to run. It is reminiscent of a FreeBSD jail or a plain old VM.
> Apple introduced launchd and nobody complained.
Just compare the source trees, you'll be enlightened[6][7].
[1] http://plato.stanford.edu/entries/self-reference/
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTM5NDI
[3] http://www.vgleaks.com/some-details-about-playstation-4-os-d...
[4] https://en.wikipedia.org/wiki/IEC_80000-13
[5] http://wiki.illumos.org/display/illumos/illumos+Home
[6] http://cgit.freedesktop.org/systemd/systemd/tree/
[7] http://www.opensource.apple.com/source/launchd/launchd-842.1...
edit: format references
[1]: http://www.illumos.org/man/5/smf
My point is, even right now with sysvinit (and aix doesn't use it afair), i have to adapt a init script to every single unix/linux distribution i want to use my software on. At least, if i want to comply with that system's best practice.
With systemd and other init replacements, it's likely a few lines of config file i have to rewrite. Its much less effort to ship or adapt to a few of these than have a init script that works everywhere.
About other unixes: calm down, this is some process that supervises other processes, this is in no way comparable to making libc incompatible. I assume we're talking about servers here that run off the shelf distributions. For (virtual) appliances and embedded devices / firmware everyone will roll their own images with whatever init they're happy with. We don't have any influence on what commercial vendors do. If AIX feels like an 80s system (i know it's modern and powerful at the core) that's IBMs decision, but i don't hear any complaints that Linux distributions don't ship ksh in vi mode as /bin/sh anymore.
So, in this particular market and with the problem at hand, i don't see how and why Linux should wait for the sysvinit replacement that is able to make everyone happy and will magically be adopted by everyone.
And if some day illumos will succeed Linux, I'm sure people will manage to port their 10 lines of service config over.
It is not ten lines of service config being hard, though, it is grokking a new, ad hoc tech, which is necessary to get the most out of it. I have not a rage against systemd in itself; it is too low level for me to care about, process management that is, yet I'd support, to the last drop of my blood, a standard to cover initialisation. If I have to write an init script/config/whatever one day, I'd rather use a standard format that I can get to work on any system, than an ad hoc, OS-specific technology that I have to re-learn every time I switch operating systems.
You seem to overlook the importance of a process hat supervises other processes. I reckon that it should be so stable, one shouldn't notice it. That is possible if and only if the thing is tested and implemented according to a standard throughout long times.
I think it's a shame most of the original page comes off as backwards thinking, Unix nostalgia and FUD like claims.
Because this one thing is actually quite important and something we should care about.
You can claim that Linux is now Unix and everything else is just niches. Great. Like Hurd. Clearly a play-thing. No point being portable enough to work there.
However back in the days, Unix was the real thing and Minix/Linux was just a toy itself. But hadn't software initially been portable, Linux could never have risen to what it is today.
When we are making an init-system with Linux kernel-dependencies, and making other core platform services like DEs dependent on this init-system again, we are tightening the bonds beyond what's useful, effectively hindering other platforms from ever gaining mass adaptation, even if they should otherwise deserve it.
SO while I appreciate systemd in general there are aspects of this development I indeed thinks deserves some more and warranted criticism.
Made my day. Emphasis mine.
When the neckbeards comes around complaining about "Unix philosophy" you can always tell them to use Slackware. And then watch them go silent.
Also the cost of maintain it and adapt applications who are tied to systemd is much more larger than adopting syetemd.
The only viable solution i'm seeing right now is: Use a mainstream distro with systemd or switch to other one which maintains their own init system like Slackware or Gentoo.
Regardless of what init system is right or wrong, the beauty of the Linux ecosystem is we can afford for different distributions each to make different decisions.
Systemd seems functionally better than both sysvinit and upstart and it certainly doesn't seem to be the root of all evil like this article makes out.
I don't believe that everyone boycotting systemd over what's currently out there will aid linux in any way.
We should not (re)write a lower level where all the components are so coupled we will be unable to change one of them with a better alternative without changing the rest.
I'm tired of all this UNIX philosophy crap. I have been using Systemd for more than a year now, on Archlinux, and it has been a delightful experience.
It works out of the box and it gets a lot of things right. Journald is quick & easy to use and a real help in finding problems. No more searching around in log files and grepping. Dependencies between services are handled by the init. Services start with maximum parallelism. Writing .service files is really easy.
It simply has better UX than any other init system, and it's supported by a lot of distros. This means standardization and progress. No more developer time wasted on sysvinit scripts.
The posted link is the same FUD that I have been reading for the last year on various forums. Even if systemd can be a single point of failure, it's still way more stable than anything we have used before.
For that tiny percent of use cases where services can do all kinds of crazy things and there needs to be extra control, other things like supervisor, foreman_god, daemontools/runit come into play. There are use-cases not many people have to deal with or even exposed to, yet are important considering the impact (say downing a major service like Gmail).
I suspect that one issue with systemd is that it aims to solve very real problem, but they are problems that not many noticed. Most of the stuff that's highlighted as benefits of systemd are things I never experienced, either I don't thing advanced enough or the issue has already been addressed by the distro.
Most of us are just going have some daemon/process that we want to start at boot and for that purpose systemd is going to look like massive overkill and overly complicated. That might be mostly a documentation issue, systemd could benefit for a "So you want to start at process" guide.
Seems the authors forgot to give themselves the credit they deserve.
https://forums.darknedgy.net/profile.php?id=589 https://forums.darknedgy.net/profile.php?id=373 http://billyest.es/About_Me
So long as I can still get syslog style plain text logs, then I have no objections. Unix and text log parsing is unparalleled. If simple text log parsing and manipulation is removed (all binary with only xml or json), then I'd be very opposed to systemd.