From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectionable with this, as there have been some absolutely inane things going on at the packaging sphere. For example, treating the fact that upstream provides a systemd unit file as a dependency on systemd. To some extent, this can also be blamed on inherent weakness in most contemporary package managers that lack the ability to easily express multiple classes of dependencies, and treat everything as a hard one.
That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth.
The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.
One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all.
To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.
Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).
Sure, that's what libsystemd0 is. It's just a shared library, like libselinux1, that lets applications be compiled with systemd support. It doesn't depend on systemd itself, or start up any daemons. It's quite possible to have a package that's compiled with support for two different logging systems, for example. In that case it would depend on the libraries for both of them, but would only actually use the one that is configured. On the other hand, it's possible an application actually does require systemd running to function, in which case it would depend on 'systemd' as well, not only 'libsystemd0'.
I agree with the sentiment of not having hard deps on systemd. In fact many teams already put some actual work toward that goal (eg. the GNOME team) but the main problem I see is who is mandated to do this work.
As an example, GNOME upstream requires logind if you don't want to rely on the bug-ridden and unmaintained ConsoleKit.
AFAIK the Debian GNOME team does not wish to enable the ConsoleKit backend on Linux due to not having enough resources to test it and nobody stepped up to maintain it. While they initially represented this fact with a dependency on systemd, but ultimately said dependency is now on libpam-systemd, which depends on systemd or systemd-shim.
So it's not like Debian teams are against what the GR proposes, but it's easy to see the GR as a way to force them to do work that they don't have the resources to do.
So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for debian to enforce "every package must run correctly under every init system" (excluding things like init-system management tools, which are clearly tied to their system).
I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?
IANADD, but actually I like this alternate proposal better:
http://article.gmane.org/gmane.linux.debian.devel.vote/17248
"Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit."
I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.
I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal.
For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work.
That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again.
The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too.
So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect:
* policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement
* upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now.
Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/
> I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal.
I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend.
This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.
There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot.
systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
systemd provides a lot more than spawning processes at boot.
It aims to provide all essential operating system deamons and a common userspace interface for them.
> It aims to provide all essential operating system deamons and a common userspace interface for them.
I think that is the reason so many people dislike it.
Replacing init - and nothing else - is something many of those people would be totally fine with. Starting services in parallel, and watching them when running, restarting them if they crash, that is something a lot of people would like very much, I am certain.
But the systemd developers did not stop there and are trying - it seems - to have systemd replace everything but the proverbial kitchen sink. I am not even saying that this is a bad (or a good idea). But doing so just rubs many people the wrong way, if only because it means the systemd people are attempting to change an important aspect of the architecture of the system without having a proper discussion about it first.
To be fair it mostly replace lots of stuff that every distribution had reimplemented in a incompatible way.
Desktop environments now have an actively-maintained cross-distro interface that they can target to simplify their life (from setting the hostname to secure multi-seat handling), so it's not a surprise that they make use of it.
Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?
If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.
I can already boot a fully functioning system without half the stuff in systemd (and in fact, there's entire distros and the entire world of embedded devices which do so).
GNOME and KDE did work just fine without systemd until they didn't. udev did as well. Samba, PAM, OpenSSH, and most of the rest of the services on my system, work just fine without it. I rather doubt that'll be the case five years down the line.
"network management, Local DNS cache, mDNS responder, LLMNR responder, DNSSEC verification, IPC in the kernel, time synchronisation with NTP, stateless systems, factory reset, OS/container/app image format, sandboxing of services and apps..."
One only need to re-implement the interfaces actually used by the DEs. IIRC GNOME had a page listing those interfaces on their wiki and systemd has remarkably good documentation about its public interfaces.
Also consider that until now many of the things you listed were done by shell scripts that every distro reimplemented differently, so if you're happy with such ugliness you can pick it up as-is. ;)
> However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd.
> systemd provides a lot more than spawning processes at boot.
And that is exactly what I think is the most irritating thing about it. I just want it to init my system. I'll do the rest, or decide which piece of software should. NOT the systemd developers.
The systemd developers don't decide that. They offer capabilities. Obviously the value proposition is attractive to other developers, thus they're using it. It's not like they're forcing others at gunpoint to adopt their tech. If you don't want to use it, don't. Pick software that doesn't rely on systemd capabilities. Or advocate that that software gets written and maintained. Or write it yourself. Or stop complaining. Just don't tell somebody to not offer a capability.
> What happens if more tools start depending on systemd? Will people just have to keep finding alternatives?
Linux becomes the new OSX (Slick, integrated, everything works great as long as you are doing the things that the system designers expect you to do); FreeBSD becomes the new Linux (Weird and confusing out of the box, but can be customised however you want it)
Which is oppositional to the unix philosophy. There will be only one permitted http server and one permitted database server, all that is not permitted will be forbidden and all that it not forbidden will be mandatory.
My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways.
That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging.
Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
Structured data is very useful. Just because many unix folks have managed to extract some meaning out of random text for so long doesn't mean it's a good idea.
This is the same thing I see about HTTP/2. It's good to finally remove a huge number of parsing errors and inefficiencies!
I'd be less opposed to journald if it used SQLite instead of its own format, but I still think that logs don't belong in a binary file by default:
https://news.ycombinator.com/item?id=7210570
The problem with sqlite for this is that as you write more and rows into a table then the writes get progressively slower -- it simply isn't able to do O(1) writes over a long period of time so you'd have to rotate the database files themselves.
I've been solving this problem by writing a non-pretty printed JSON blob to one line in a log file. Structured, but still text and very easy to stream. I build a separate binary index that gives more efficient time based lookups, but it isn't needed to understand and process the log file.
No. It's in a monitoring system we've been working on, but the principle is pretty simple. We may well end up open sourcing quite the rest of it sometime in the future -- a lot of the code already is.
People already complain about systemd dependencies, I'm sure pulling in SQLite would have generated more complaints than a quite simple custom binary format. :)
Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise.
Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
And that's part of the problem. Some systemd parts makes sense for server, some make sense for desktop, but trying to select just those that fit scenario X is a pain in the behind.
To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. New changes are good or bad, let's give people more choices, the better one will eventually win, or they just co-exist, that's how the nature works, systemd is no different.
How much are you willing to pay for those choices? Each init system doubles your testing load, which is already a concern, but more importantly it also means that there are features which are either need to be dropped or which will require time developing abstraction layers for multiple init systems.
That might still be worth doing but this is a lot more than saying “Oh, if you don't like vim don't install it”. All of that will require time, effort and be a source of bugs / UI clunkiness which no other operating system has to deal with – I'd much prefer that people pick 1 system and spend time getting closer to the “it just works” level which OS X and Windows have been at for years rather than maintaining a stable of patches and extra code.
I have experienced issues with launchd which do not exist in the components that it replaced (e.g. cron, init, etc).
For example, try setting a cronjob that runs every minute in launchd (e.g. running fetchmail). launchd says, "process exited too quickly" and disables the entry. [I'll note that this was an old example. Hopefully it's been fixed, but it's been far from "just works".]
I was talking about the normal user experience which systemd is designed to handle – e.g. hotplug a USB camera and Chrome can use it for WebRTC.
In this specific case, launchd is designed as an init replacement which keeps processes running. The restart throttle is designed to prevent crash loops which are horrible for battery life and tends to fill up logfiles, so it expects the process to run for at least 10 seconds. The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time.
> The easiest way to solve that would be to use it as intended and run fetchmail -d rather than spending the extra overhead restarting fetchmail all of the time.
fetchmail is also intended to run as a system daemon as part of a full-fledged mail system. This isn't always the case.
Also, launchd not just initd, but crond per Apple's consolidation of system daemons. That is a use-case for crond. If Apple wants to replace crond, then they should make sure that the replacement works. I'm sure that I could find other programs that might exit in under 60 seconds that don't have a daemon mode[1].
[1] To be clear it wasn't the 'run every minute' that was causing issues, but the 'exits less than 60 seconds after it starts' that was tripping it up. I could run fetchmail every 10 minutes, but when it is able to connect/verify that there isn't new mail in under 60 seconds, then the whole process gets disabled. Oops!
Why can't it look at the exitcode? If you exited with success why does matter how long it runs? The faster it is done with running processes the faster it can go back to sleep.
Think about it from the perspective of the operating system vendor: J. Random Codeslinger never checks return codes and always exits 0 so launchd ends up running the thing semi-constantly until syslog fills up the disk with "Usage: …" messages.
If you have a professional sysadmin monitoring things, this gets fixed.
If you're the average Mac user, you tell all of your friends that the last OS X release sucks and made your Mac slow and eventually go to the Apple store when your hard drive fills up.
What if the system process that you want to run periodically takes less than 60 seconds to run? Why should I have to wrap it in a shell script that ends with 'sleep 60' just to accommodate Apple?
Linux has been at the "it just works" level for decades, where it matters -- on servers and appliances. It's "Linux on the desktop" where apparently boot times are a big deal requiring screwing up the entire operating system for.
And not even there, in my experience; my laptop and desktop reboot once every few weeks or longer, usually for kernel upgrades, and even with legacy init, bios-to-login-screen is not the longest part of that process. For interactive machines, systemd is already a complicated solution for a simple non-problem. For servers, it's worse.
The first few trivial counter-examples which come to mind:
* someone adds a storage device. Now your server can't boot because what used to be /dev/sda1 is now /dev/sdc1. Yes, UUIDs partially address that but unless you were defining "decades" as "within the last year or so" you can't assume that they were used.
* init script starts something, which crashes / is killed by OOM / etc. and you'd like it to be restarted. Note that this is still unsolved with upstart if the process crashes for more than your respawn limit, as is common with e.g. networking-related startup failures but, hey, it's the same braintrust which required multiple major releases to accept that sysadmins need logging and daemons to be started as users other than root or that "hang forever" is not a valid error handling strategy.
Nobody adds a storage device and ends up changing the boot drive on a server. I've never even heard of that in three decades of changing drives on servers. It never even happened with SCSI.
And in the rare case where automatic restart is a good idea, I wrap that script in a supervisor, like monit, as god intended.
If a process is crashing for more than the supervisor's respawn limit, then you have a problem that computers can't solve. Not sure how you thought that could be resolved automatically.
> Nobody adds a storage device and ends up changing the boot drive on a server. I've never even heard of that in three decades of changing drives on servers.
It's not especially common, particularly if you don't work with large servers or tons of local storage. Here are three variations on this theme which I had to deal with:
* The Linux kernel changed the order of device enumeration in a point release (early 2.6, if memory serves). This caused some of our servers to start enumeration the on-board IDE CD-ROM ahead of the SCSI drives and on the next reboot the ones which had been setup before Debian started using UUIDs in /etc/fstab failed because /dev/sda was now the CD drive.
* A very similar problem happened involving USB mass storage, which was a problem because our remote administration tools could forward a local drive or ISO image to the remote server as a USB device. This was particularly annoying on one early KVM system which only forwarded the device when you were connected so the logical device ordering changed if you rebooted it while connected to the console.
* If you have multiple controllers in a system, the drives are enumerated in order per-controller. If the bays were not fully populated when the system was first setup, a new drive added to controller 1 will be enumerated ahead of the drives from controller 2 and all of the subsequent device names will be shifted by one.
All of these are why it's now routine to use UUIDs to identify drives. It's a solvable problem but hasn't been so for even a single decade.
> And in the rare case where automatic restart is a good idea, I wrap that script in a supervisor, like monit, as god intended.
Uptime and resilience are baseline requirements for what I work on, not "rare cases". I've used external supervisors but that's introducing a third-party tool with its own bugs and means that you can't assume that another sysadmin is familiar with it. If you're the monit person in a supervisord shop (or vice versa) you'll probably have something take longer to debug or break at some point because of a subtlety in the differences between the two.
This is such a common case that it makes sense to solve it once at the system level, particularly since that allows me to e.g. not have to code an extra bit in my daemon that knows how to ask arbitrary third-party supervisors about a different process.
> If a process is crashing for more than the supervisor's respawn limit, then you have a problem that computers can't solve. Not sure how you thought that could be resolved automatically.
That's a fine approach if the failures are caused by something like a broken config file but it doesn't handle environmental failures gracefully. For example, consider a daemon which fails if it can't resolve a hostname or connect to a server (e.g. a database) or which exits if it can't write to disk. In either case, you're going to have downtime if the server / data-center drops offline or a partition fills up.
The question is whether the service comes back quickly after the underlying problem is fixed or requires someone to localize it and restart the process. If you have one server and you happen to be on-duty, this isn't a big deal but for anyone with many servers running different apps it can be a headache after a network partition or power failure (oops, web servers all came online well before the database server finished checking its RAID array).
In the case of upstart, the default respawn limit is only 10 times within 5 seconds after which it will stop the job until you manually restart it. Since they didn't add throttling or delays, there's no way to deal with this within upstart without either increasing downtime for every error (e.g. adding "|| sleep 10" to every script) or wasting more CPU restarting jobs as quickly as possible until you hit a larger limit.
Again, not an unsolvable problem but had they not ignored a huge amount of prior art and perhaps even consulted with actual sysadmins there would be things like a respawn delay and backoff so you could say things like "restart this no more than n times per minute". Instead, most places either convert everything to use a different supervisor or support an external monitor which requests restarts for services periodically, both of which add maintenance overhead and risk for what is a standard feature on other systems.
> Linux has been at the "it just works" level for decades, where it matters -- on servers and appliances.
Like hell. Anything beyond the most basic tasks on a server (and even the most basic tasks, sometimes) requires configuration, and often that configuration ranges between "nonintuitive" and "actively spiteful." If a service crashes and the pid file doesn't get handled properly, you've got to go in there and fix it. And god forbid you have to touch SELinux for anything. "Just works." I want what you're smoking.
Why are you using Debian then? Debian is about flexibility, they build for an insane multitude of architectures and they offer Hurd and FreeBSD kernels even! With every package imaginable, Debian maintainers already invest a lot of work in supporting all of this. They work very hard to automate tests and builds in order to minimize this effort level and manage to create a high quality, flexible system.
If you don't want flexibility but instead want a single ascended choice system like on OS X or Windows, use RHEL or one of the forks of it instead. Debian may simply not be the system for you.
> Why are you using Debian then? Debian is about flexibility
That's really a fundamental misrepresentation of Debian. As a Debian user since around 1997 or so, the value has always been that you get solid, tested packages which work out of the box – almost everything you need is an apt-get away and it's consistent across all of the systems with the same packages installed. When I was responsible for somewhat over a hundred systems (servers & desktops) that was invaluable for delivering a consistent user experience.
Maximum flexibility would be something more like Gentoo where you can play around with config options and rebuild software with arcane flags, with the expectation that you're comfortable spending time diagnosing anything which breaks if you hit a combination which hasn't been well tested by anyone else.
This is highly relevant to the discussion above because consistency starts becoming a LOT more work when you start needing to coordinate between multiple major projects. If you want, e.g., Firefox or Chrome to be able to use a webcam just after it's plugged in that requires communication a bunch of large code-bases (kernel, GNOME, audio daemon, browser, probably some sort of permission system which may or may not be in one or more of these, etc.) and all of that is either going to be harder or slower if you have to support a bunch of different systems with differing designs, bugs and it's a tax which people who don't support Debian won't have to pay.
Remembering the era where people just accepted that things like audio or video wouldn't work on Linux because it was too much hassle, I appreciate the value of a single target.
>To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think.
Oh, it's an amazing idea. So I assume you candidate to be a fulltime maintainer of the whole software stack and packages, right? Why don't we support OSS4 too, while we're at it! After all, support for everything is just free of man hours!
How about merging all linux flavors into one so we have one system like MacOS? or Windows? hi they each have lots of different versions to maintain, what a waste of resources.
systemd by all means is still new, how can you convince all of us that it is _the_ init system all of a sudden?
It's good to have options, for each apps(email,web server,database,you name it) in Linux there are normally a few options too, why is systemd that different?
The fundamental problem here is that desktop Linux users, who have absolutely had a bad experience over the decades, have gotten so tired of incompetently executed half-assed solutions that they now grab at any other solution with the fervor of a drowning victim.
Why have they gotten to this point? Because the people working on desktop have generally been the D-team. The A-team is working on kernels and infrastructure, the B-team turns out packaging, and the D-team has been coming up with hair-raising stuff like gnome, 'desktop bus', pulseaudio, enlightenment.
So this weird little monoculture has emerged in which no other concern matters except that they get rescued from drowning -- that their boot times (!?!?) go to 5 seconds from 10, that hot-plugging USB drives (!?!?!?!) be wrapped in with the init system if it helps at all, that DHCP (!!??!?!?!?!!) and core files (!!!!!!!!) and all logging (!!!!?!?!?!?!?!?!) be taken over in the name of helping even 1% on the core experience.
But at the same time, two basic axioms of reality still bear:
1. Linux on the desktop is irrelevant and will never win, both in terms of the Linux story and in absolute terms; and every scrap of effort that goes into it has been objectively wasted for two decades and will continue to be wasted.
2. Linux everywhere else has been working fine for longer than most of the desktop people have been alive.
following from (2), the people who run servers recognize that although systemd has some good ideas, it forcibly bundles together a grip of super bad ones too, and is clearly implemented by people who don't understand systems outside of the desktop.
The attempt to turn Debian back into a distribution for everyone, rather than a small collection of desktop people, is completely valid and sensible. That said, it's totally clear why the desktop people want it this way, and why they have such a misguided emotional investment in their terrible new windows emulator.
To be fair, some of the ideas behind pulseaudio are good:
- Unify all of the different audio systems that existed: OSS, ALSA, esound daemon, etc...
- Network accessible sound. Years ago I was able to setup pulseaudio to stream audio from my HTPC to my laptop where I had headphones plugged in. The process to do this wasn't entirely user-friendly, but prior to pulseaudio, people would setup yet another audio subsytem that every app would then need to support on a case-by-case basis.
As the existence of CoreOS proves, much of systemd benefits are not desktop-oriented, and I can assure you that many systemd developers/maintainers are not desktop developers but experienced sysadmins/developers.
Thas said, while I may agree with the spirit of the GR, like I may agree with the existence of the Hurd and kFreeBSD ports, I wonder who will do the work needed to patch and support other init systems, given that up to now no-one bothered putting some actual work instead of pretending others should do it.
At least the Hurd and kFreeBSD porters were kind enough of carrying out most of the effort themselves, even if unfortunately I don't think it was sufficient.
(And no, please, systemd has nothing to do with Windows, please avoid such baseless comments which only manage to start useless flames)
Not again... I think this was already decided..
Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times are noticably faster.
Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?!
I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.
Please do not dismiss legitimate issues as personal attacks. Just because you did not hit issues, doesn't mean others didn't. My experience was quite negative:
- Binary log files, which are also prone to corruption and crashes
- Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.
- The need for unnecessary things like dbus to be run at startup
- Complication of some simple configuration tasks (in my experience on Arch at least, network configuration was a bitch)
- udev has apparently been hijacked and may cause issues for those who don't want systemd
All in all, it feels like change for the sake of change to me, I see no advantages which I desire, and several minor to moderate disadvantages, but learning and using it is pushed on me for no reason. Personally, I've moved to running FreeBSD, it's simple and stable, though I've been considering Debian/kFreeBSD, I'd be sad to see it go. But it's the farthest of the issues with systemd IMO.
As far as your boot time improvement goes, that's great, but modernly, my systems are either always online or suspended to RAM or disk, rarely rebooted.
FreeBSD removed the "crud" by standardizing all of the tasks people want to do into rc.subr. As a result you get some pretty clean and easy to understand rc/init scripts except in extreme circumstances.
Run a cron job on sysvinit; add one line to /etc/crontab.
Run a cron job on systemd; create two files: one timer unit (about 5-7 lines) and one service unit (about 5-7 lines) that you have to name identically (minus the extension) with the timer unit.
sysv init can launch a cron daemon which itself can run cron jobs.
systemd can launch a cron daemon which itself can run cron jobs.
in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks.
If you select the same cron daemon, the configuration of cron jobs may be performed in an identical manner, regardless of which init system has launched that daemon.
Are you complaining that the optional systemd timer functionality is difficult to use and that you would prefer to run cron jobs via a dedicated cron daemon? That may be a valid criticism, but I am a systemd user and I have never tried this functionality, so I cannot comment on it. I personally continue to use a cron daemon since this is what I am familiar with.
Do you have a philosophical objection to the init system providing such capabilities? Maybe there is a valid reason to have such an objection, but I do not hold this perspective personally.
Regardless, your comparison here is not valid, since you are comparing the process of configuring optional functionality in systemd (which has no equivalent with sysv) to the process of configuring a cron daemon (which you could just as easily be using with either init system).
in addition, systemd can also execute timer units periodically. This is functionality that sysv init lacks.
You present this as if this makes sysvinit somehow lesser because of it lacks the ability to execute timer units. Sysvinit doesn't have that because that capability is completely unrelated to what sysvinit does. Although one could argue that the system as a whole provides that functionality through cron anyway, so there'd be no need to have sysvinit do it.
Good comment. I think part of the problem is that some systemd proponents are pushing using it for far too many things. Such as replacing cron or configuring network interfaces. Here's why I was complaining about the network configuration thing on Arch:
I have in my mind CoreOS which does not provide a cron daemon nor any way to install one. So using systemd timers is the only way to get cron functionality.
> Binary log files, which are also prone to corruption and crashes
Why are they more prone to corruption? Software bugs aside they should actually be less prone to corruption, because they allow you to verify if corruption has happened. syslog has no such mechanism.
> Unnecessarily complicated and unfamiliar init script structure. I feel like I went from one that was arguably too verbose to one which is too vague.
Yeah, right...
> The need for unnecessary things like dbus to be run at startup
Why is dbus unnecessary? It’s a great way to do IPC. So great that it will be implemented in the kernel as kdbus.
> Complication of some simple configuration tasks (in my
experience on Arch at least, network configuration was a bitch)
The init system was never responsible for setting up your network. Even before systemd, Arch recommended netcfg/netctl instead of setting it up in /etc/rc.conf.
> (in my experience on Arch at least, network configuration was a bitch)
What exactly about this was hard?
I have one config file - /etc/wpa_supplicant/wpa_supplicant-wlan0.conf - which you can add to simply with wpa_passphrase "MySSID" "MyKey" > /etc/wpa_supplicant/wpa_supplicant-wlan0.conf
Then I ran a couple commands once:
systemctl enable wpa_supplicant@wlan0
systemctl enable dhcpcd@wlan0
And now it happily connects to any of the wireless networks I've set up in the config file.
If I want to control it or switch networks or reload my config, I can use wpa_cli to do this easily.
Totally minimal, no need for NetworkManager or netctl or anything, and works flawlessly.
Obviously if your net setup is more complex, this could require a better tool, but most of weird stuff would be done with iproute2 or whatever.
I had a personal dev server running arch with a simple static IP. I had tutorials on arch telling me to manually create and edit systemd scripts to start and stop the interface, then add and enable them. To configure a simple static IP, which should be an extremely trivial task.
Now compare with FreeBSD, just add 1 single line to /etc/rc.conf and I'm done, 2 if I want a default gateway too.
Also, our of curiosity, do you know what systemctl enable does? What files does it modify and how would you do it on a remote system (ie: one you'd mounted)? Would you need to chroot?
You are comparing apples and oranges. Network management in Arch was replaced by netctl. It’s very easy to set up your static network that way (you just have to edit 1 line).
systemctl actually tells you what it does as output. It symlinks a service file from one directory to another. You can always do that by hand.
Frankly, that's a poor way to do it. A much better way would be to simply run `systemctl enable dhcpcd@eth0` and then edit the dhcpcd config. https://wiki.archlinux.org/index.php/Dhcpcd#Running And/or have your IPs configured by a DHCP server.
Sorry, but all your reasons are no bugs or technical problems. Frankly, it seems to me that this is your inability to accept change.
Yes, sometimes we need to embrace new things and learn new things. That doesn't mean they are bad.
And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init just because you might or might not use Debian/kFreeBSD at some point in the future (instead of FreeBSD in the first place).
If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd.
(FYI: As of February 2014, popcon registered 130 kFreeBSD, compared to 32 HURD users, and 165,821 Linux users. )
P.S.: I reboot my laptop everyday, i don't suspend.
> Frankly, it seems to me that this is your inability to accept change.
I'm more than willing to accept change if that change is at all beneficial. Systemd simply fails to offer any beneficial changes to me and several harmful ones. You're right, they're not so much technical issues or bugs as usability and system philosophy issues. But issues which should not be simply dismissed nonetheless.
So, please, tell me, why should I accept change just for the sake of change? Especially when those changes seem to be against the philosophy of a simple, easy to understand system.
EDIT: thought I should note this too
> And sorry, but i don't see how 99,9999% of Debian users should stay on sysv init
I'm not suggesting that they do. By all means, change the default if most users desire it. This post is simply about allowing for flexibility of init system. I don't see why you have such a problem with that.
If i remember correctly kFreeBSD even is in such a bad unmaintained state the the discontinuation of it is discussed. Yet, you bring it up as an argument against systemd.
It's not, that was a lie. You're free to join #debian-kbsd on OFTC to see that development is ongoing and active, and that there's more than just one maintainer. They've switched to the 10.1 kernel and they frequently commit to Git.
Not really a deep Linux user here but systemd brings the bad bits of windows to Linux: Abstract stateful configuration, black boxes and communications to do simple tasks. As someone who supports lots of software built on this approach (windows desktop) then I will assure you it's a pain in the butt big time.
Sure it may work for you but if N machines have state A and P machines have state B then getting all N and P machines to state B is incredibly difficult. It looks easy until you do it. That's probably one of the largest and most common things we do when deploying more than a trivial single machine.
To put it into perspective, everything becomes as much of a PITA as RPM packages without yum.
That was immediately obvious to me when I installed CentOS 7 on a couple of test machines to replace our costly Riverbed appliances and timedatectl threw "failed to issue RPC" on one machine but not the other. Same steps to install.
That's where we don't want to go.
We are now running FreeBSD and nginx on a HyperV cluster.
Abstract stateful configuration might be a bad thing, but having a configuration file execute arbitrary, complicated code sounds like a much worse thing to me. I would be interested in differing opinions, but I think in another context the words "executable configuration file" would be a cause for deep concern.
I disagree. If nothing else, there is a lot of precedent for executable code in configuration roles. MTAs, build systems, desktop environments, text editors (vim, emacs, joe, others) and probably a good percentage of the uses of tcl. Problems arising from this don't seem to be universal in any category (except possibly build systems, depending on how you look at it.)
But I have a question: where is this coming from? What makes you think it's "a cause for deep concern?" I would agree it's overkill for most software, but an init system for an operating system like Linux (or configurations for most of the kinds of software mentioned above) is never going to be simple.
I don't know of any executable configuration files on any Unix derivatives. There are init scripts, but they are not configuration; they are instructions.
There are scripts with metadata attached (rc.d items) which may be ambiguous but that is no different from a shared library containing an export table or a set of runtime linker dependencies.
Systemd unit files, as far as I am aware, are functional replacements for init scripts. They do contain executable code, which is perhaps unavoidable. However, they are primarily what you would call a configuration file. Given that they are functionally equivalent to init scripts, init scripts must also handle configuration.
You're making a semantic argument, not a technical one. Why is it a good thing that your init system consist entirely of executable scripts? Because to me that sort of arbitrary executable code would be something to minimize: abstract out common functionality, DRY, and have each component do as little as necessary. If you believe otherwise, please support that idea.
I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc.
I would gladly switch back to Debian if I could swap systemd out for something else.
Yea, I didn't actually try systemd on Debian because of the unstable-ness. I actually tried it on Fedora, and like I said, had nothing but trouble. Normally I would fight through it, file bug reports, etc, but the benefits of switching to systemd didn't seem to be worth it. When I see debates about systemd, I rarely see compelling technical reasons from _either_ side. The only technical reason I can see to move to systemd is improved boot times, which doesn't seem worth it when (like someone else in this thread mentioned) most of your systems are either always on, or suspended to disk.
EDIT: I should probably also say, my desktop GUI setup is rather sparse. I usually run a debian server edition with SLiM & XMonad, which starts up ridiculously fast no matter which init system I am using. So, systemd seems a bit like overkill for my usecase.
First, I think the work in Debian to support kfreebsd and hurd is pretty important. Fringe (for now), but important.
But more importantly [ed:than what is good for just Debian], a Linux monoculture would be a bad thing. We need (open)solaris, openbsd, freebsd, netbsd and OS X - which means any Linux-only, not-very-portable solution to these things just should not be mainstream. Consider that jails on freebsd works with, but do not demand, zfs. Even if arguably zfs solved a lot more real nuisances and problems than systemd does.
Last time systemd was mentioned, I addressed the issue of the journal, and how it being prone to corruption on bad crashes didn't really help its utility. There's room for improvement in init handling (see eg daemontools/runit) - and there may be a case to replace init. But so far I've yet to see any compelling arguments for systemd that have much to do with systemd. And their stance on portability, and complexity demonstrate to me an absolute ignorence of risk: portability, simplicity and small components are effective tools to mitigate risk.
Probably the most compelling argument is that simple services can now have simple config files rather than complex redundant shell init scripts - but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs (iow those that have pretty straightforward demands).
> but it must surely be possible to take a simple config and generate a correct script for most of those services that really benefit from simple configs
The nosh init system[0] supports exactly this, although it outputs nosh scripts rather than shell scripts. nosh is an execline-style interpreter and set of commands for that interpreter that implements a simple init system where almost no code is run unless you explicitly ask for it to be run. It also supports configurable logging, socket activation, and some compatibility with other init systems - it could be a significant part of an alternative to systemd.
A Linux monoculture would be a bad thing for users, but it'd be very beneficial for big Linux-centric companies like Red Hat - if everything depends heavily on Linux-specific functionality, there's less risk of another Unix they can't offer like Solaris coming along and eating their lunch.
Those very well might be better, in the technical sense, but none of them seem particularly compelling to me. None of those solve a problem I am having (or have had). Change is fine, I will happily learn a new init system when it provides solutions to my problems, but switching because "the current init system is old" doesn't seem worth it to me.
I've also noticed that the unit ordering and dependency chains can be quite flimsy and slow, occasionally freezing entirely before the display manager is started.
Since you switched to systemd on your laptop and everything is ok, I have to inform you that on Wednesday I switched my PC to systemd and nothing was ok to the point where I had to install another Linux distro and lose some good hours in the process.
Systemd has been trying to drag desktop linux into a world that is as seamless as OSX and it is so sad that most people blast it as "not the linux way". And even sadder that people type this on Macbooks.
The truth is that the West has moved on from Linux - Apple has won. Linux is most relevant in Asia, where we want to run it on cheap, locally assembled desktops. SystemD is bringing so much to improve the state of desktop linux - it is enabling fundamental security like XWindows-without-root[1], service dependency management ,etc.
there is a lot of fud around binary logs (which incidentally are append only and have a grep like interface built around it) and hard dependencies on systemd for any cgroup access. The second is actually kernel mandated - all cgroups have to have a single arbitrator for external applications. Direct access to cgroups will be dropped in the future. AFAIK, as on today systemd is the ONLY arbitrator that complies with the kernel-dev requirements.
I'm keen to see where desktop Linux can go to - I believe that it is going to be transformative for India. I strongly believe desktop Linux initiatives like SystemD and Mir/Wayland is going to take us there
That said, if you have worked with Docker - I find myself wishing very frequently for SystemD as pid 1. Right now I use supervisord as PID 1 (for a multiprocess container) and it is definitely more difficult to use than SystemD. Plus the ease of imposing resource limits (using systemd.resource-control) is simply unparalleled
[1] http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
Actually, that is another systemd FUD. SystemD enables stateless systems - now that I think of it, very similar to Docker - by clearing out the /var and /etc directories. Which means that when you reboot the system, it acts as a system reset. This is actually, pretty hard to actually implement and systemd is trying really hard to do this.
Imagine being able to build your own private DigitalOcean and able to have pristine machines for a new fleet deployment (possibly even avoiding the stale confidential data issues plaguing DigitalOcean).
[stateless] is actually, pretty hard to actually implement and systemd is trying really hard to do this.
Support for stateless has existed in RedHat based distributions since at least 2003-2004. I, in fact, used it to run a ~50 seat callcenter using read-only NFS root systems, with a dynamically populated /etc, a decade ago.
And that pretty much encapsulates, what systemd is attempting vs what people think it is attempting.
Systemd is not innovating on ideas, but on implementation. How do you make things like service dependencies, stateless systems, etc consistently possible.
It is bringing something which was possible only for a person of your skill level, down to mine.
I would say it is the same difference between Ubuntu and Arch - idiotproofing the Linux ecosystem.
That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth.
The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.