I recently discovered that systemd supports drop-in config files so I'd recommend putting the changed settings into something like /etc/systemd/resolved.conf.d/disable-stub.conf. That way your package manager isn't upset that files it controls are modified.

I wrote a personal blog post about this (https://www.turek.dev/posts/disable-systemd-resolved-cleanly...) to try to help people out.

> You know you turn that DNS server off by adding "DNSStubListener=no" to /etc/systemd/resolved.conf right?

I suppose you could do that. although I prefer: systemctl disable systemd-resolved systemctl mask systemd-resolved

Then it's dead and will stay that way.

Then.. why does it exist? More importantly, why is it enabled by default?

Does systemd want to be an init system? A logging system? a dnsmasq replacement?

Systemd is a replacement for Unix.

Folks at Red Hat noticed that the Linux userland architecture is not convenient for what they would like to build. So they are building systems which replace the traditional mechanisms: first DBus, then systemd, which is an umbrella of many services: init + service monitoring + containers, logging, interactive login, some networking, etc. I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.

> Systemd is a replacement for Unix... I suppose that in 10 years a linux kernel + systemd could be a complete system, with little need for other userland.

'Doing many things, none of them well' is actually the opposite of UNIX.

https://en.wikipedia.org/wiki/Unix_philosophy

This needs to be stated yet again apparently - systemd is not one monolothic binary, it's a collection of tools in one repository.

Centrally developing many disparate pieces of software from one repository is what every BSD does so you can hardly argue that it's not "UNIX".

This is setting aside that systemd actually does all of those things better than the tools that came before. journalctl and systemd timers are fantastic. And good luck using the alternatives to manage cgroups.

A monolith does not necessarily mean a single binary.

Sometimes you want a different balance — say, in embedded systems. If you think about busybox, it does something similar, only doing a better job at looking like the traditional userland.

There is nothing bad about it. What I find bad is forcing everyone to jump on the same bandwagon, no matter which bandwagon. If I wanted choices made for me, I'd buy a Mac.

ugh, I was so excited when my POWER9 arrived... and then I started looking at the OpenBMC stack.

There is a "project" named systemd and an "init system" named systemd, in much the same way that there's the GNU project and GNU-$everything.

Nobody says things like "what is GNU? Is it a kernel, a compiler, a libc, a build system, a set of userspace tools?".

Likewise, the systemd project has many utilities under its umbrella, and most of them are completely optional.

Hm. GNU exists to unify software under a single philosophical umbrella - the thing that all GNU software has in common is a fanatical attitude to software freedom.

What does all systemd software have in common? What's the unifying principle there?

I think the best answer is that systemd-the-project tries to be the things that all of the different distros historically had to do themselves, the things that didn't have an upstream, but maybe deserved to have an upstream so that they could be reused by other distros, and maybe benefit from more eyes and more engineering effort.

Each distro used to have to roll their own initscript system (with varying degrees of compatibility), so they made `systemd`. Each distro had their own init script to save/load the backlight state, so they made `systemd-backlight` (if you're going to replace the initscript system, you'll also have to replace the things that the initscripts for that system did). Each distro used to have to roll their own network configuration scripts (Debian's /etc/network, Arch Linux's netcfg and later netctl, ...), so they made `systemd-networkd`.

Some of this class of thing got picked up by other projects; each distro used to have to roll its own initramfs system; today Dracut exists, so systemd won't be doing that (unless the Dracut folks decide to team up with the systemd folks--remember gummiboot? gummiboot renamed to systemd-boot).

In one of your other comments you wrote "in my opinion that implies more modularity than it posesses." While there are some nasty couplings (it'll take some patching to get systemd-nspawn to work on a non-systemd system), you can successfully use many of the systemd modules on an OpenRC system; it is a lot more modular than people give it credit for.

But why does it need to exist in the first place when my system has exactly 0 change in behavior when it's disabled?

The functionality provided by the stub resolver is documented in the man page[0]. You may not be using it, but other people are.

[0] https://www.freedesktop.org/software/systemd/man/systemd-res...

Or disabling and stop systemd-resolved should do the same thing.

Thanks for the tip.

It wasn't quite the solution I was looking for. I wanted my DNS server to "just work" for people who downloaded it—I didn't want to force them to re-configure systemd to accommodate my software.

Tweaking my software to accommodate systemd.resolved took ~4 hours. It was an enjoyable dive, but I'd rather not have had to do it on the first place.

I continue to think it's a bit of an overreach for Fedora to include a DNS server by default.