systemd-imds

dimich · 2026-06-26 22:10:56

systemd-261 introduced some "Cloud IMDS (Instance Metadata Service) tool".
I know that there are many cloud use cases, but not every PC running systemd supposed to be used with some clouds.

I understand services are inactive until enabled. But the package installs units, policy and dedicated user which will never be used in many installations. Why not to implement this so wanted feature as a separate project? If systemd core requres some changes to implement it, let there be required changes in new release. But why ship everything together?
What can we do against this awful systemd policy except switching to systemd-free distro? I wouldn't really want to switch from Arch.

mpan · 2026-06-27 05:26:47

Arch Wiki wrote:

(Arch Linux) ships software as released by the original developers—upstream—with minimal distribution-specific downstream changes. Patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.

— Arch Wiki → Arch Linux

As you correctly observed, the features needed to offer support for IMDS aren’t enabled by default. So what kind of issue do they cause to you?

Which policy do you refer to with the mention of “awful systemd policy”?

5hridhyan · 2026-06-27 06:25:34

What can we do against this awful systemd policy except switching to systemd-free distro?

Nothing, unless we compile it ourselves, which most of us don't want to do.

I wouldn't really want to switch from Arch.

Same here.

Last edited by 5hridhyan (2026-06-27 07:00:59)

seth · 2026-06-27 07:39:27

mpan wrote:

Which policy do you refer to with the mention of “awful systemd policy”?

Tell lennart to stop the mission creep and dump half-baked stuff into the systemd-bucketd. I assume this is the main objection here, too.

There obviously some split packages and arch could™ try to keep systemd-core and systemd-kitchensink but there're limits to what this can achieve because of the libsystemd-centric design.

AEU-wise (arch end user) one could maintain a "system-lessdumb" package which is basically some NoExtract rules, but it would be more of an "out of principle because you're doing it wrong, lennart" thing,

Lone_Wolf · 2026-06-27 14:16:03

Yup, NoExtract rules are an important part of my setup.

I have to combine that with masking some services/sockets/automount and systemd-generator tweaks though to be really effective.

dimich · 2026-06-27 19:37:33

mpan wrote:

As you correctly observed, the features needed to offer support for IMDS aren’t enabled by default. So what kind of issue do they cause to you?

At minimum they take up storage space. They take bandwidth during updates. Of course, it is negligible now, but the trend makes me worry.
It installs yet another system user and authorization policy.
Today it is inactive, tomorrow it is activated as a dependency for some other service.
As a user, I want to understand what is installed on my PC, why it is installed, what it is needed for. And of course, if it is not needed for my setup, I want to be able to safely uninstall it without a risk to break something.

mpan wrote:

Which policy do you refer to with the mention of “awful systemd policy”?

Installing a bunch of services and utilities as an integral part of "System and Service Manager".

5hridhyan wrote:

Nothing, unless we compile it ourselves

Actually, as users we can tweak installation with NoExtract mentioned above. However, it isn't very convenient to maintain a sheet of NoExtract entries.
Perhaps it would be possible to split systemd into separate packages. However, I can imagine what a burden is to maintain such split, so don't even suggest to do this. And currently it can be only implemented by selective copying one or another file, with the same effects as for NoExtract.
A service manager should be separated from a set of services at upstream in the first place.

mpan · 2026-06-27 20:28:23

Dimich: so there is no issue at all. It’s your personal preference that’s also selectively applied to a singular project.

There is nothing wrong with having preferences. But presenting them as something objective is not going to work. Equally nothing wrong with having an expectation that preferences are being respected. As long as it’s applied at a similar level to all projects. Which is not the case here.

Above all, being clear about your true motives and what leads to them. Instead of replacing them with a poorly hidden rant, followed by rationalization. That really helps with communication. And either finding a solution, or readers skipping the topic if expressing anger is the only motive.

I for once prefer using ALSA as my sound system. And don’t like GNOME⁽¹⁾ pushing their vision. Many others here do too and we may sympathize with your position. We are happy to help in limiting some effects. But that’s not going to happen if you’re not honest about the motives. It doesn’t mean people will not try to convince you it makes no sense. It doesn’t mean people are going to not discuss it. But if, instead of demanding package maintainers to adjust the entire workflow for you and threatening to leave if they don’t, you’d rather ask about maintaining control over your system in this and that scenario, it would be much more productive.

Units may be masked using `systemctl mask`. This is likely what you wanted to prevent a specific service from being started.
____
⁽¹⁾ Or rather some part of it. I know it’s not the entire project, hats off to most of you there.

Last edited by mpan (2026-06-27 20:28:52)

twelveeighty · Yesterday 01:02:10

I have no doubt that OP's underlying concerns are shared with many Arch users, myself included. But I agree that they weren't stated with a rationale and supporting arguments.

I like the idea of splitting systemd into an "init system" and "everything else". But this likely means forking upstream, removing the "non-init" code [*1] and then maintaining it, which is time consuming. Does anyone know of a similar (systemd-fork) project, perhaps from other distros that are already doing that?

[*1] I have no doubt the definition of "non-init code" is up for debate, but I have faith that things like systemd-imds would get removed

dimich · Yesterday 02:02:02

mpan wrote:

so there is no issue at all. It’s your personal preference that’s also selectively applied to a singular project.

If actual state doesn't meet personal preference, it's an issue. Shipping diverse unrelated parts of software in a monolithic bulk is also someone's preference. But in software it's called "bad design".

mpan wrote:

But if, instead of demanding package maintainers to adjust the entire workflow for you and threatening to leave if they don’t

Threatening? Neither systemd developers or Arch maintainers obligated to satisfy user's preferences. However, it is not forbidden to discuss software flaws and possible ways to fix them (I hope). Typical answer to any software criticism is: "if you don't like it, don't use it". I only stated that such "solution" is already known and should not be proposed.

mpan wrote:

Units may be masked using `systemctl mask`.

I know how to manage services. However, not installing unwanted service is much more proper method to prevent it from runing than keeping it's unit file, executable and other related files, then creating a symlink to /dev/null.

I got your opinion, thank you for sharing it.

seth · Yesterday 08:38:04

Shipping diverse unrelated parts of software in a monolithic bulk is also someone's preference. But in software it's called "bad design".

… or "kernel"

Threatening?

While many people™ (strong people, big people. tears pouring down their computers) actually never figure *why* holding your breath until you get what you want doesn't work on *any* level, I assume this was just a colloquial recap of your stance, not literal.

discuss software flaws and possible ways to fix them (I hope)

"Hope is not a strategy" - the lennux problem has been discussed since the dawn of systemd.
Since the only reasonable way (file an upstream bug letting lennart know that you are doing it wrong, lennart. is unlikely to work for various matters of conspiracy theory you'd likely end up w/ maintaining a downstream fork, somewhat akin to gentoo's elogind - or dropping systemd altogether
Both have their drawbacks (maintenance against - as in "in opposition to" - an active upstream / 3rd party userspace hard-depending on systemd) and a split package that "just" keeps some files out of the main package does actually not really address any of the design flaws w/ systemd (random things randomly mangled by an ABI-unstable libsystemd instead of specified protocol/interface and also state machines do. not. scale!)

So until "doing away" w/ systemd fixes more problems than it causes, people will tolerate the disadvantageous status-quo. Slow boiling frog phenomenon.

I'm sorry, but realistically this discussion will go where it has in the past 15 years: nowhere

mgeins · Yesterday 12:25:29

thank you dimich.

usr/lib/systemd/system/systemd-imds-early-network.service
usr/lib/systemd/system/systemd-imdsd@.service
usr/lib/systemd/system/systemd-imds-import.service
usr/lib/systemd/system/systemd-imdsd.socket

systemctl mask systemd-imds-import.service
systemctl mask systemd-imdsd@.service
systemctl mask systemd-imdsd.socket
systemctl mask systemd-imds-early-network.service

- enought?
- are there more "problematic" services?

Lone_Wolf · Yesterday 14:03:24

The masking may help, but you have to interfere earlier.

https://man.archlinux.org/man/core/syst … rator.8.en

mpan · Yesterday 17:10:17

mgeins wrote:

- are there more "problematic" services?

Please don’t get deceived. There is nothing wrong with this service. By masking it like this, without any real reason to do so, you achieve somewhere between no visible effect to breaking something. And in the latter case, since you will forget it’s masked, irritating people when that breakage happens and you seek help here.

What you just did is like taking a hammer, smashing a random part of your machine, for no reason at all, and then coming and asking if there are other parts you should hit.

ReDress · Today 10:17:37

mpan wrote:

What you just did is like taking a hammer, smashing a random part of your machine, for no reason at all, and then coming and asking if there are other parts you should hit.

I didn't not coming. Also, it doesn't hurt to smash something if you have already been considering removing it.

If something claims to be "private" but I saw nullptr, then I am not sure I should keep it.

Last edited by ReDress (Today 10:19:29)

Arch Linux

#1 2026-06-26 22:10:56

systemd-imds

#2 2026-06-27 05:26:47

Re: systemd-imds

#3 2026-06-27 06:25:34

Re: systemd-imds

#4 2026-06-27 07:39:27

Re: systemd-imds

#5 2026-06-27 14:16:03

Re: systemd-imds

#6 2026-06-27 19:37:33

Re: systemd-imds

#7 2026-06-27 20:28:23

Re: systemd-imds

#8 Yesterday 01:02:10

Re: systemd-imds

#9 Yesterday 02:02:02

Re: systemd-imds

#10 Yesterday 08:38:04

Re: systemd-imds

#11 Yesterday 12:25:29

Re: systemd-imds

#12 Yesterday 14:03:24

Re: systemd-imds

#13 Yesterday 17:10:17

Re: systemd-imds

#14 Today 10:17:37

Re: systemd-imds

Board footer