systemd-userdbd cannot be disabled #15175
Comments
It is used by |
I am using Logind, but every feature of it that i am using, is running perfectly fine without But even if this design is a choice for whatever reson, shouldt there be a warning when is try to disable systemd-userdbd. It could say that the service will be started by logind anyway. Instead it teslls me that the service will not be started at the next boot, even though this is not true. |
|
It is socket activated so you need to disable the socket too. But since the socket is currently enabled by default in socket.target.wants what you really need to do is |
It's lightweight and generally useful, so it should be enabled by default. But users might want to disable it for whatever reason, and things should be fine without it, so let's make it installable so it can be disabled if wanted. Fixes systemd#15175.
|
not sure I get this? why disable this at all? it's a tiny daemon, and shouldn't matter at all... Disable it during compilation if you don't want this. Or use "systemctl mask" on the service and its socket unit. But I see no point in supporting "systemctl disable" for it, it's a low-level system component, and not supposed to something configurable? |
poettering
added
the
needs-reporter-feedback ❓
|
It still takes up lines in |
|
@mmonaco then disable userdb during build? |
|
or mask socket and service? |
|
To be clear, I am masking. I stumbled across this issue and was trying to help and wasn't really looking for an upstream change -- however I do think it would be nicer if these services were opt-in like most others. I don't think build-time changes are a reasonable suggestion for most people who are using distro packages. |
|
it's very low-level stuff. I mean systemd-tmpfiles or systemd-logind or so are not something you can eanble/disable either. For low level stuff there's mask/unmask, if you feel like it. Only for high level stuff we do enable/disable... |
It's lightweight and generally useful, so it should be enabled by default. But users might want to disable it for whatever reason, and things should be fine without it, so let's make it installable so it can be disabled if wanted. Fixes systemd#15175.
This is the exact opposite of a good design reason. It even checks out as a violation of "security by design", considering that any well designed system should only run the minimal number of services needed. Having systemd run this by default on billions of devices without good reason is a really bad choice. Disabling at compile time is also not a solution for distros, as some user will want to use these services even though most won't.
If this is a design choice it should be communicated as such and above all else, the systemctl command should give a reasonable feedback if it is used to disabled such a service. But this bug report is rather about this unnecessary service being enabled by default, which as said, is a bad design choice and a waste of ressources. Considering this service will be running on a lot of devices, even with only minimal ressources used, this is a waste of a lot of enery. Since systemd seems to enable more and more services by default like homed (which I am generally a fan of) we could sooner or later probably turn of a power plant or two if systemd were to turn stuff like this off by default. Please do not underestimate the consequences of having a service that only few user have a use case for, be enabled by default on pretty much all linux systems. There is not a system design guide out there that does not recommend disableing all unnecessary service. Systemd should respect this as well. |
keszybz
removed
the
needs-reporter-feedback ❓
Honestly, the only reason I can agree with this, is because there's one place where systemd either can't(yet) or won't be implemented in, and that's user-facing router devices and other embedded low-ram/resource devices. Excluding shared memory size, and the fact I didn't compile systemd with uclibc; I did heard somewhere that some notable developers of systemd don't see point in daemons that were created by openwrt that are fit for their purpose of running on low ram low performance routers(namely, ubus, init system etc.), but I can't really put enough of a confidence in whether my memory serves me right, so while I will keep this post as is. The other alternative is well "just buy a router with at least 256MiB of ram instead of 64MiB", but that doesn't work for repurposing old routers or for running an up-to-date 3rd party firmware secure home router. Well I just stumbled on userdbd when looking up what runs on my vps, wondered what it is noticed what it is, what it does and then stumbled upon this here. And as I typed it all out it has long been closed. |
|
@kubast2 on a router you'd turn off userdb at compile-time. Services in systemd can be turned off on multiple level: at compile time, via "systemctl disable" and via "systemctl mask". For userdb the first and the last is implemented, this bug report is about getting the middle one ("systemctl disable") implemented. I am not convinced that's necessary, and in particular your router usecase is better served with disabling it at build time. |
systemd version the issue has been seen with
Used distribution
Expected behaviour you didn't see
Unexpected behaviour you saw
Steps to reproduce the problem
Why is this service running in the first place?
I have no use for it and therefore it should be disabled by default until the user activates it.
The text was updated successfully, but these errors were encountered: