Sad news today: systemd-resolved to be deployed in Ubuntu 16.10
lists.dns-oarc.net
lists.dns-oarc.net
Why are people constantly trying to demonize Canonical?
I haven't seen any single subsystem harm the linux eco-system as much as systemd has and while I understand the desktop vendors clout in this the server is where linux shines and that was territory that was hard won.
If all systemd had done was offer an alternative init system then that would have been a non-event, to take over the entirety of the linux system side tried-and-true and battle tested utilities is irresponsible at best and dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.
Modular designs are good, monolithic designs are bad. Dependencies are bad and so on. Lots of choices at the design level were made against fairly hard won knowledge on how to architect complex software systems. All these dependencies translate into 'all or nothing' and that is never a good thing in the software world. It's just another form of lock-in, something that the world of closed source software is good at and I'm quite sad to see it pollute the world of open source.
Edit: I suspect a lot of the pushback against systemd - mertited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.
If we never replace things with better things, we'd be using superpowered DOS machines to this day. I don't get the "knowledge has to be discarded and then has to be replaced by different knowledge" argument if the new knowledge is of a better tool.
I'm not all in with systemd's ethos, but I don't see a significantly better tool around.
> when disks were mechanical
DISKS are STILL mechanical. They will always be. That is why it's called a disk. You thinking is limited to fancy laptops and not considering enterprise servers.
> If we never replace things with better things
Better? That is far too strong. Things are not always better but making certain use cases easier. That does not mean it's better. Systemd has nice features, indeed; but it's also limiting in terms of losing the capabilities of full blown shell script. Sometimes this latter is very handy.
Edit: Downvote? Nice. Try commenting instead.
There are niches, such as long term archival, backups, etc. where disks may still be competitive, but even those are rapidly being eroded.
For things like web servers or database servers, I'll never provision another machine without SSDs.
All of the servers I manage except for a few legacy ones are SSDs by now, for the simple reason that they are cheaper to operate at this point:
They consume less energy, and while their price per GB is high, their IOPS per GB is high enough that we can get away with far fewer replicas of each item of data and still get good enough performance.
I can't afford not to use SSDs in every new server we provision.
Not using SSDs in your servers today means you're behind the curve except in certain niches where performance doesn't matter but sheer storage volume does. That too is set to change within the next couple of years with current rates of cost reductions.
From the little I know, socket activation seems to be systemd's main attractive item.
> It wasn't broken, so it did not need fixing / rewriting.
Writing a robust init script in shell is a HUGE pain. Every distro seemed to have their own tools and methods for writing init scripts (e.g. Red Hat had /etc/init.d/functions, Debian had its own, Ubuntu had upstart) -- all of them sucked. systemd makes it easy (and for the most part, portable across systemd distros).
In trivial case, it's simple in any modern distro [1]
In non-trivial case, it's complicated. And the complexity is not going away, all you can do is move the complexity to one corner or another.
When you add the complexity to the shell script, it's right there, plain and clear.
When you move the complexity to systemd, it's not magically goes away - it just moves to thousands of lines of C code (of not the best quality on this planet, to say the least).
[1] https://wiki.gentoo.org/wiki/Handbook:X86/Working/Initscript...
You're ignoring that complexity was added to every single init script. Every init script had its own potential bugs, issues, race conditions, dependency logic, etc etc.
Now you're moving it to one single master system.
No, it's not "magically going away". The repetition is going away. The code duplication of an extremely complex system is going away.
depend() {
need localmount
after bootmisc
}
reload() {
ebegin "Reloading configuration"
start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/}
eend $?
}I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this.
It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.
Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.
To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.
. filename or source filename allow one script to effectively import another. This means that the various logic can live in one place and be reused.
Here, people are complaining that systemd replaces the name resolution system. People also complains it handles tmpfiles, the random devices, the journal, etc... People complains that it replaced perfectly working, battle-tested components with new, unaudited code.
I don't personally care one way or another, btw. I'm a happy systemd user. But I understand the concern.
But, well, since I saw a 5-year-ago Stackoverflow question recommending double fork to daemonize which goes against process management best practices dating back to 1990s IBM AIX, I realize the Internet is not smart enough to get such delicate things straight. Maybe djb stuff was not easy to find. Whatever.
*"Portable across systemd" is not portable at all.
But it's not "taking over" anything at all. People choose to use these components.
And yes, it was and is broken. With respect to specifically DNS, have you tested the various documented options for resolv.conf, for example, and confirmed what your resolver actually does?
I have, and on several different systems with different distros, what I found was that none of them behaved as documented. DNS resolution on most Linux distros is badly deficient, which is one of the reasons so many applications pull in their own resolver libraries, and one of the reasons so some distributions end up e.g. running local Dnsmasq instances to farm out the actual resolution to something that's easier to get to behave in sane ways.
DNS has been broken on most linux systems for a long time. If you read the ubuntu mailing list post, this is the problem they are solving:
* On servers, cloud images etc. we did not have any local DNS server. Configured DNS servers (via DHCP or static configuration in /etc/network/interfaces) were put into /etc/resolv.conf, and every program (via glibc's builtin resolver) directly contacted those.
This had the major drawback that if the first DNS server does not
respond (or is slow), then *every* DNS lookup suffers from a ~ 10s
timeout, which makes every network operation awfully slow.
Addressing this was the main motivation for the blueprint. On top
of that, there was no local caching, thus requesting the same name
again would do another lookup.
Never mind that if you have several programmers on RH payroll on the same project, it is quite possible for them to use corporate channels to make decisions and then effectively dump that into the codebase over night.
I don't see Debian or Arch developers making that argument.
Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?
It is rather that RH can throw dollars and thus coder man hours at a problem while most other distros have to make do with volunteers (or can't field the amounts RH can).
Then again, there is a certain email from Poettering thats of interest.
https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
> "Google's strategy is clear. Play Services has system-level powers, but it's updatable. It's part of the Google apps package, so it's not open source. OEMs are not allowed to modify it, making it completely under Google's control. Play Services basically acts as a shim between the normal apps and the installed Android OS. Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break."
The absorption of udev and basically forced dependency on systemd from important desktop environment projects also controlled by RH is a very real reason why this happened.
> Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so.
> Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff.
> If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more.
https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
It's just that people against it are extremely vocal.
I do dislike the idea of binary logs, though.
journalctl could use some work, but it can just print JSON, and there's jq.
I'm familiar with dealing with text files in Linux/Unix land and have built up years of knowledge on doing so. I feel reluctant to throw that away.
There is a fork of Consolekit out there, Consolekit2, but they have to contend chasing logind's tail as most DEs have either stripped out their consolekit support, or it is suffering from severe bitrot.
However.
In the beginning a lot of distros were "forced" to accept systemd because udev was merged into its codebase.
Systemd is great, but its group of devs are absolutely fucking terrible at public relations. Sometimes they make changes that upset users. Like the recent one that has (logind?) by default killing all user-created processes when the user logs out (this surprised people as it became a new default). Or the security incident before that where systemd made it possible for users to get access to framebuffer contents. Sometimes things happen.
It's just made worse when you go to the systemd group with your problem and they act like what they've done is correct and everybody should just live with it. Sometimes we're wrong, sometimes they're wrong. Poettering writes up these really long posts which are mostly good reads, but sometimes he calls us neckbeards who want to live in an unchanging, static past.
Great project, great code, great devs - but terrible attitudes [sometimes].
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221
* https://news.ycombinator.com/item?id=11782364
The systemd developers' way of addressing that was to go and ask the people who wrote things like tmux to change tmux. The response of the tmux developers was to repeat the question asked and not answered 5 years ago.
* https://news.ycombinator.com/item?id=11798515
* https://news.ycombinator.com/item?id=11797075
The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going.
That's evil. Thanks for pointing that out. Terrible to debug, poorly documented and funny side effects you don't immediately think off. That fork bomb reasoning for the change is also sketchy as if you have local privilege you can DoS the machine in a lot of other ways (cpuburn, filling the disk, hogging memory and causing swap of death). If you run a public SSH server you likely already used cgroups and other measures to prevent fork bombs.
Here is one answer from an Arch developer about why they adopted systemd:
https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
"From 2brainz (Former Arch Linux Developer for Init Scripts"
> I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts. Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another. In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent. With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd. Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies). Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks. The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well. No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups. Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it. Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking. Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us. I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does. So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.
Most of the arguments against systemd are emotional arguments.
My personal feeling is this: systemd might be a software blackhole that eventually eat and destroy everything it comes close to and that's OK. If it is so bad then other developers can create a new or modified system that keeps the good stuff and eliminates the bad stuff, while working with other software projects to integrate better.
If we're stuck with systemd, is is better than others worse than some and it isn't like it is the first highly opinionated software project to grace us. A new ecosystem will get developed, wikis written, books sold, training courses packaged. Wise developers of other software will whisper in dark corners about the evil that stalks the land in the form of bad code and design of systemd, and crazed developers will haunt Slashdot, Hacker News, and LWN holding up the hand-lettered signs to make sure we understand how terrible Lennartitis is.
If something new comes along (more modular! less Lennart! doesn't insult the tender heart of tmux developers) developers will fight it out and we can go back to the 5 init systems that we're currently using.
OTOH, Nosh offers a tool to auto-convert service files into equivalent daemontools shell scripts: http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...
Few seems to care enough either.
History of modern init FYI: http://blog.darknedgy.net/technology/2015/09/05/0/
And as the concept of containers and *aaS/cloud took hold, some of the same things that benefited said laptops was found to benefit containers.
The reason systemd happened over any of the others though was that perhaps the main dev had a penchant for NIH solutions, and worked for the 800 pound gorilla of the Linux ecosystem...
See here systemd, pulseaudio, lvm, selinux, kvm, many more.
Some of these things are good, some of them are bad. The important thing is once RH has decided they want to take over another component of the ecosystem there isn't really a lot anyone can do. Not even Linus has been able to halt the systemd nonsense.
Why do other distros cave? Well because RH controls most of the other important projects too and they go to great lengths to create integration that is unnecessarily difficult to decouple. For instance Gnome. Probably impossible to run without systemd now (or at least highly impractical).
At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.
RedHat is a premium member of our community that has a well earned reputation which makes whatever they do get noticed. Why are they to be the focus of a witch hunt like if they were MicroSoft of the Steve Ballmer era?
If these things didn't solve problem they wouldn't get used period. RedHat being an evil member of Linux seems almost comical. Linux has won the war and yes RedHat has been a key member in winning the technology war. I fail to see how all distros who can do whatever they want continue to chosen RedHat solutions over and over again? They make developers lives better and arguably Linux better.
Canonical on the other hand continues to be a Linux community member that tries to compete with everyone else and doesn't contribute upstream as much as everyone else. I say it is good news now we can have less wasted work on different solutions. Why hasn't Canonical's projects caught on? They don't work as well or seen to not work as well as other solutions. Unity anyone?
PulseAudio has been a HUGE success that so many talk down due to the rocky start of the project and the personality of the developer (Who also created SystemD) Audio in Linux was a huge mess prior to Pulse Audio.
KVM - is the best virtual system bar none.
lvm - I don't really need to defend this project?
selinux - This was started by the NSA not RedHat
I am just saying if RH wants something to become the dominant solution it will be, regardless. Doesn't matter if they started the project, or acquired it, or if they just think it's a good idea, or maybe it's just something a subset of their clients want (i.e selinux).
It's not about competition either. Canonical is a terrible example. They are tiny compared to RH in terms of presence in the community. Their efforts are basically safe to ignore because they are downstream of everyone else.
The issue at hand is just how much of the upstream that RH has a stranglehold on.
As I said. Sometimes it's good, sometimes it's bad but even if it's mostly good it doesn't mean that it's not happening.
But it's also a load of unrelated utilities like this one. Unfortunately if you get systemd as an init system, you generally get all this other stuff (unless you take steps to remove them, which in some cases is simple and in others is painful).
Some of these utilities might be a good idea, but they should be separate projects, not bundled.
jdebp % cat /var/sv/epmd/service/run
#!/bin/nosh
#Run file generated from services/epmd.service
#Erlang Port Mapper service
move-to-control-group epmd.service
setuidgid rabbitmq
userenv
epmd
jdebp %Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.
I don't understand why systemd is taking over or what benefit it has bought. It works for now, is that enough?
It feels like a monstrosity of overly complex and questionable design. Yet, it spreads. Throwing "unix philosophy", a most agreeable set of ideas, out the window.
Maybe I'm just being reactionary and slow to adapt.
Any good recommendations re: Linux distros that follow the Unix philosophy closely whilst still being up to date in terms of packages?
For server maybe you can give OpenBSD a spin for its fame of security.
First, please, let's get the unix philosophy crap out of the way. Most of the modern Linux tools don't follow it. The people who passionately hate on systemd for not following the unix philosophy happily use Grub2, LibreOffice and whatnot. The Unix philosophy is nice to have, but quality software that does not follow it exists, nonetheless.
The advantages that systemd has brought are hard to downplay. It gets a lot of hate because they're essentially non-existent for desktop users (and don't give me that shit about dynamically mounting storage devices or parallel startup and whatever, because those were available way, way before systemd was a thing). The unpleasant truth is that desktop Linux is largely irrelevant for a lot of the major players in the Linux world, and for the very few who care about it, the only relevant target is corporate workstations, where a tight integration with systemd is desirable.
tl;dr it has real advantages which are desirable to most of the companies that pour money into Linux stuff and, unsurprisingly, these can dictate much of Linux development at the moment.
So, what is the advantage systemd provides to companies?
- It offers a single, easily-configurable way to define startup tasks, issue various system-level commands (shutdown, suspend etc.), which is immensely helpful when you write a daemon that has to write on a dozen different targets. The official story is that SysV was nice and easy because it was just a shell script and we loved that. Truth is, writing startup scripts was a heart-wrenching adventure in figuring out the subtle differences between distributions. Systemd's solution is not better, IMHO, but it is certainly far, far easier...
* ...which is a big deal when, now that Linux is suddenly the next big thing (especially in make-belief markets like IoT), you have to suddenly convert swarms of Android and Windows programmers to Linux programmers. Especially on platforms where there's a lot of integration and packing work to do (which often gets outsourced to someplace where programmers are cheap and super-specialized), this is useful, because it's a lot easier to teach people to write systemd service files than it is to teach them to write shell scripts.
* Having a unified system for virtually every system-level task reduces the surface on which your customers can exercise their creativity, which reduces support costs.
* For companies that write Linux software, as opposed to "just" integrating it, having a standardized system for virtually every system-level task means that, as long as you stick to using that interface, your software is going to run on whatever distribution or platform you deploy it on. Historically, this was problematic on Linux, as every distro did its subtly different thing and, consequently, you had to test on every distro.
Edit: just to be clear -- these are all good things. My beef with systemd is related to its community's attitude towards reliability and bugs, the abysmal documentation that surrounds not just systemd, but its entire entourage (like D-Bus), its developers' lack of concern for anything that is not systemd or Gnome and runs on something other than their laptops, and the aggressive PR around it, the result of which is that a) now there's a bunch of systemd bigots who keep trying to push it into everything, even where it doesn't belongs, and b) there's another bunch of anti-systemd bigots who insist it's the doom but won't code a damn line to give us something else, and I have to keep explaining why systemd is OK sometimes.
Not one or two, all of them. Writing an initscript started with copying the template from /etc/skel, and it was already pretty long. Compare that with the actual init scripts from FreeBSD/OpenBSD. Some are literally 3 lines long.
My issue with systemd is that there is no clearly defined scope. It started as a "SysV init replacement", which it clearly isn't. SysV is an init system, while systemd is more of a service manager that can also run as a system's init. When comparing the two, or even systemd vs {upstart, nosh, you name it} what are we even trying to compare ? systemd does init, service restart, tracks user's process and sessions, manages your network (systemd-network), your logs (systemd-journald), your devices (systemd-udevd), how your system syncs time (systemd-timesyncd) and I'll stop here because the list is long. IMO, it does too many things and it appears the various components are rather tightly coupled.
Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.
Unfortunately, a lot of the BSD wisdom is lost on people who try OpenBSD on their laptops, can't figure out how to connect to wifi without NetworkManager or wpa_supplicant, and automatically conclude it's arcane shit from another age. Clean init management is just one of the lessons that Linux could learn from there.
> Others have mentioned the code quality; I can't comment because I haven't looked at the code. One thing that really bothers me though, is the tight coupling with dbus. It doesn't matter how good the systemd-* code is, if dbus is borked then your whole system goes down with it. I can debug a misbehaving init script by starting it with sh -x. With dbus, it's a nightmare.
I've read the systemd source code here and there. At line level, the code is actually pretty good, idiomatic and clean. I don't remember seeing any obvious blunders.
Engineering-wise, I've seen better. The lack of a serious debugging infrastructure is just one of them, and that plagues pretty much any D-Bus application, not just systemd. A lot of features are gratuitous/unneeded, exist just because the developers couldn't bother to read documentation or didn't like the defaults of some tool so they wrapped it in a systemd interface, or simply because of Gnome.
Then again, a lot of things are badly-engineered and we run them. The only thing I very strongly dislike is the deployment/distribution model. It's a huge suite of tools of massive complexity; at any given time, for any given version, at least one of them is basically of beta-level quality, which means that, for any version N, you end up knowing at least one or two workarounds for a set of bugs. Then N+1 pops up. The old bugs are resolved, but now two other tools have been added, another one has been rewritten because reasons, and now there's a new generation of bugs that you have to learn and remember. The fun grows exponentially with the number of platforms that you need to support; I now know about, like, more than a dozen systemd bugs across five versions, because I have to support targets that use five different versions. I'm a walking bug tracker at this moment.
Edit: I know this is technically "the distributions' fault", but sometimes you don't quite have a choice, e.g. when working with whatever SDKs a manufacturer provides, or when dealing with systems where upgrades are difficult and infrequent for various reasons (regulatory, remote access etc.). Devops is not the answer to everything.
This reminds me of http://thedailywtf.com/articles/XXL-XML and the "XML fever" that infected most of the enterprise and otherwise software developers many years ago. Whenever I see some system XML-ifying everything, it's usually a good indicator of grotesque complexity elsewhere in it too.
This is caused by resolved requiring a separate forwarder. "XML" isn't inherently bad.
"D-Bus is low-overhead because it uses a binary protocol, and does not have to convert to and from a text format such as XML." https://dbus.freedesktop.org/doc/dbus-specification.html
No, it's not: https://dbus.freedesktop.org/doc/dbus-specification.html
> "XML" isn't inherently bad.
Yes, it is (well, as a data format; as a markup language it's ugly but serviceable). XML is incredibly verbose, arcanely complex and a colossal time-sink of man-hours which could have been spent on pretty much anything else in computing. It's the JavaScript of data formats (which is amusing, since JavaScript's data format JSON is actually not half bad).
> we picked "resolved" as that [...] does not require D-Bus (unlike dnsmasq)
-- https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...
systemd (by leveraging cgroups) makes it easier to 'track' started processes. It makes it easier to stop/kill processes. It also provides handy security features (e.g. PrivateTmp).
All the recent talk about systemd is about the other components that replace certain basic userland compoments.
logind for sessions changed the default to kill background tasks on logout, now it's about the implementation of the dns resolver that comes with systemd. There are other implementations that replace cron, ntpd, syslog...etc.pp. All of this has a dependency on glibc and uses dbus.
This has nothing to do with init scripts. This is an attempt to improve on the status quo of userland tools close to the OS. systemd appears to provide some minimal userland that comes with a Linux kernel and aims to be a userland API. I personally think this is a bad idea but I kind of see the point why you might want to do this.
The IMHO absolutely warranted criticism for some of these replacements is that they are not better designed, that they create new dependencies and complicate things without reason and there is a tendency to create some systemd specific API that userland has to implement - breaking compatibility with other POSIX systems - something that was hard to do even before systemd.
So it's not about init scripts - it's about revamping essential userland tools in a way that's badly designed according to some.
Personally I hold no grudge against this but I'm not keen on using this or having to deal with this as a sysadmin. It's a undocumented black box once you have run into problems and you are busy reading C code or capturing dbus calls. I have usually better things to do.
And for the initscripts - you could have done this with runit/s6 and mkdir with cgroups in 2008 if you wanted. You could have used setsid before that. This was deprecated and now systemd (or something else that implements the kernel API) is the whole mananger of cgroups.
I personally think the systemd way is not the right direction to take as it's horrible inflexible and will bite Linux but I can understand why you might disagree here strongly.
I don't know much about it, but even from my position of ignorance it's clear that the level of debate is very low.
I guess the debate is so toxic because it's a perfect bikeshedding topic everyone that uses Linux can somehow participate in. Some sysadmins are surely frustrated because it breaks the way they worked in the past years, others are happy about the new features.
I'm undecided but if I read this https://news.ycombinator.com/item?id=11675129 I'm really feeling uncormfortable. Hitting this and debugging it seems like a nightmare. So I guess it's a win and eases a lot of pain points for ordinary users but make the live of specialists a lot harder. I can imagine how you hitting these bugs regularly turns you into posting something in the angry territory.
On the other hand the debate is now mostly technical (except some trolls).
There seems to be a line drawn where those that do web hosting and similar love systemd, while other server admins loath it for introducing needless complexities.
I have taken to thinking about web hosting as "uptime by machine gun". This in that they achieve uptime not by maintaining solid server configs, but by rapidly firing containers and/or VMs at the problem until it goes away.
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
That is a feature not a bug.
It was bizarre to me that a few years ago even changing your host name at the command line was different between the various Linux distros.
That was one of the things that the systemd people set out to remedy, in fact. Now, you run a Desktop Bus client that talks to a system-wide Desktop Bus server using a Desktop Bus protocol.
* https://freedesktop.org/software/systemd/man/hostnamectl.htm...
* https://freedesktop.org/software/systemd/man/systemd-hostnam...
But perhaps I'm biased: I just had to use chattr to keep the &/!&%"/! NetworkManager from overwriting /etc/resolv.conf. All these things just worked 10 years ago.
While I massively dislike the systemd approach, this is not true either. Using wifi, mobile connections on linux were a massive pain unless you already spent countless hour on writing your own fixes for you own setup.
10 years ago most resolvers did not use source port randomization no one had DNSSEC deployed.
djbdns had had it since the previous century, MaraDNS for 5 years, mine for roughly the same, and PowerDNS for (I think) 1.
The RFC terminology for in-application DNS client libraries is stub resolvers. RFC 1034 section 5.3.1. A resolver in contrast is the complete subsystem, sometimes implemented as a stub resolver together with a separate program that it makes remote procedure calls to, that does query resolution. RFC 1034 section 2.4.
Yes, it's arcane terminology. It's not mine. I've been telling people to think of DNS like HTTP since the turn of the century. But if you use it, use it correctly.
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/dn...
What client side dns libraries did source port randomization in 2006? AFAIK it wasn't until 2008 when most things were fixed.
People keep talking about the good old days before systemd where everything worked perfectly, but that ignores the fact that things were pretty broken.
If you care about things like local caching and failover, things are still pretty broken. Most unix systems are horribly fragile out of the box. You either run something like dnsmasq or unbound locally or use a hack like https://github.com/kvz/nsfailover. A large number of distributed systems completely grind to a halt when the primary name server fails (if only everyone used anycast...)
Basically, if you rely on the system/glibc provided DNS resolution on most Linux distros and you want reliability, your best bet is to run a local DNS server and point everything there either way.
That's not changing with systemd-resolved in the state it is today, but who knows, maybe someone actually paying attention to the resolver stub will finally make that situation improve.
Please give examples.
That's going to be very inconvenient for laptop users...
[Match]
Name=wlan0
[Network]
DNS=8.8.8.8
FYI - android fires a request to http://clients3.google.com/generate_204, I'm fairly confident windows/ios/mac/ubuntu all do something similar.
Maybe the author is biased but the list of issues and potential vulnerabilities is so long that there could be CVEs reserved now waiting only for the release of software.
depend() {
need net
before inetd
before xinetd
}
Make a note that systemd-resolved is not systemd, merely "part of the systemd umbrella". -resolved is not widely deployed at all.
I don't know enough about resolved to comment on this new development, but as a sysadmin I much prefer systemd as an init system.
And that is perhaps the red line. Those that have embraced systemd seems to be made up of cloud/container/web people that worry about being able to take something from 1 to 1 million servers in a heartbeat.
Those that do not see the need are all those that for years have been running Linux using sysv or alternatives on the backend for various uses.
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
* http://blog.darknedgy.net/technology/2015/09/05/0/
and realize that you've brought out the same old tired red herring again.
See also Hacker News:
Honestly, at this point, why not rename SystemD to svchost.exe and set it up to use .reg files for configuration?
There are things I don't like about it, but overall it makes my experience administering servers far more pleasurable.
> It won't work well with applications that have their own DNS code inside. Such as browsers.
The systemd developers have addressed M. Wouters' charges as follows. Such applications are classed as
> legacy software which does not use libnss-resolve
-- https://github.com/systemd/systemd/issues/3420#issuecomment-...
and
> legacy DNS clients
-- https://github.com/systemd/systemd/issues/3420#issuecomment-...
The systemd developers maintain that
> programs really should use NSS (with nss-resolve as backend) or resolved's native bus APIs, but not talk DNS themselves.
-- https://github.com/systemd/systemd/issues/3420#issuecomment-...
> > source port randomization is enabled by default to further protect against DNS spoofing attacks.
> [...] source port randomization is pretty useless [...]
-- Paul Wouters, https://lists.dns-oarc.net/pipermail/dns-operations/2016-Jun...
> ATM resolved uses randomized ID fields [...]. It does not use source port randomization though,
-- Martin Pitt, https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...
> I'm concerned what this says about the maturity of the project: djbdns introduced source port randomization back in 1999.
-- Seth Arnold, https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/0393...
> ... as you are most likely just doing DNS on the local network.
http://linoxide.com/linux-how-to/systemd-boot-process/ for how it starts up
https://lwn.net/Articles/604609/ cgroups https://lwn.net/Articles/531114/ namespaces
https://dvdhrm.wordpress.com/2013/07/08/thoughts-on-linux-sy... logind/sessions/seats
http://0pointer.net/blog/projects/socket-activated-container... and finally "the series" from the horse's mouth :)
After that you can use whatever you like.