[subway]

It sounds like you don't understand the tools you use, and have no interest in learning them. NetwokManager (just like any other daemon) cannot "re-enable" itself. It's possible if you were on an Debian derived host that package post-install scripts enable the service (as is the case with all services on Debian derived distros due to packaging policies. The right way forward here is to indeed remove the package if you aren't using NM. Or better yet, get a better grip on the packages you install in the first place, and just don't install NM to begin with.

If you're on a RH or Arch derived distro, policy is just the opposite, and if the service is ever magically enabled (aside from Anaconda enabling it after the package was selected at install time), it's a massive bug (I can't find any such bug report in Arch or Fedora).

[rconti]

No, it's just that, for the purpose of an internet forum comment, I don't wish to revisit years of regular and maddening problems across fleets of thousands of servers. Over the years they may be subject to different initial build and deployment regimes, to say nothing of different OS versions that may have been released over that time, and various Puppet manifests that may have been changed over that time.

When something is regularly found to be the problem, and has never made my life any easier, it gets yanked. Sometimes I may have had time to analyze further, other times it may have been an emergency. Regardless, it's been at least 1.5 years since I worked in that environment, and my memory has faded. In the real world, we don't have infinite time to analyze infinite failures.

Here's what I remember:

NetworkManager = problems.

No NetworkManager = no problems.

You may care to look down on people who don't always have the time to analyze every single occurrence of every single problem to the nth degree, and subsequently catalogue the exact cause and fix for reference when posting on forums in the future, and that's fine.

My opinion is, it sucks, and I don't want it.

If you like it, and enjoy its benefits, please do. I'm not denigrating you for your choice.

[bubblethink]

systemd's dependency logic about what is enabled or disabled is not straightforward. For example, I disable buetooth on general principle, and yet it gets enabled (as in activated) in some scenarios due to other stuff depending on it (i think something in gnome does). "systemctl is-enabled foo.service" is not a guarantee about anything. Something else can still start the service without the user's authorization.

[JdeBP]

> enabled (as in activated)

Not understanding the difference between these is likely part of the problem here.

[bubblethink]

It's not really the user's fault though. If you really want to make sure that something else doesn't start it, you need to mask the service. But then, you can't start it either. What you really need is "disabled unless I start it". I don't think there is a state like that.