[systemd-devel] systemd-userdbd and other stuff running all the time

[Reindl Harald]

Am 04.09.20 um 17:37 schrieb Lennart Poettering:
> On Mo, 24.08.20 13:40, Reindl Harald (h.reindl at thelounge.net) wrote:
> 
>> is taht growing amount of services running on all systems really
>> necessary and why are things like "repart.service" and "homed.service"
>> are started "static" which makes the concept of enable/disable things
>> more and more obsolete
> 
> neither userdbd nor homed are static. Just disable them if you really
> don't want them. "systemctl disable" works for them.

not for userdbd - it's fired up and eating nearly 2 MB RAM - add that on
a host with 100 vuirtual machines

> repart is conditioned out if you have no drop-ins for it. Which I
> assume you haven't. hence no need to disable it. Moreover even if you
> have drop-ins this is a oneshot service only. it runs at boot and
> exits quickly.

check a growing amount of folders and files at startup is hardly for free

[root at rawhide ~]# systemctl status systemd-repart.service
● systemd-repart.service - Repartition Root Disk
     Loaded: loaded (/usr/lib/systemd/system/systemd-repart.service; static)
     Active: inactive (dead)
  Condition: start condition failed at Fri 2020-09-04 17:42:38 CEST; 59s ago
             ├─ ConditionDirectoryNotEmpty=|/usr/lib/repart.d was not met
             ├─ ConditionDirectoryNotEmpty=|/usr/local/lib/repart.d was
not met
             ├─ ConditionDirectoryNotEmpty=|/etc/repart.d was not met
             └─ ConditionDirectoryNotEmpty=|/run/repart.d was not met

> userdbd is activated on demand and exit-on-idle btw. it exits after
> 25s of no client making any request. if you have it running this means
> stuff is using it.
> 
> userdbd provides a sandbox for NSS modules to clients that want to
> user/group lookups. the idea is that we can avoid loading network
> facing code to be loaded into each and every process that way, which
> is security-wise highly problematic.

adding more complexity to systems only using local users is also problematic

>> lrwxrwxrwx 1 root root    9 2020-05-28 09:06 systemd-homed.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root    9 2020-07-06 17:45 systemd-repart.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root    9 2020-08-06 18:48 systemd-timesyncd.service
>> -> /dev/null
>> lrwxrwxrwx 1 root root    9 2020-08-24 12:47 systemd-userdbd.service ->
>> /dev/null
>> lrwxrwxrwx 1 root root    9 2020-08-24 12:47 systemd-userdbd.socket ->
>> /dev/null
> 
> Well knock yourself out, but masking is not necessary, you can just
> disable homed/userdbd/timesyncd if you don#t want it, and repart is
> conditioned out anyway, so masking doesn't really get you much.

well, when i see them from time to time running or in "systemd-analyze
blame" disable alone is obviously not enough