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
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.
> 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).
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.
> 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.
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.
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.
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.
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.
>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.
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.
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?
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?
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)
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Summary: