Re: [systemd-devel] systemd-userdbd and other stuff running all the time
Am 04.09.20 um 17:52 schrieb Reindl Harald:
> Am 04.09.20 um 17:37 schrieb Lennart Poettering:
>> 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.
well, tell why it is still running on a firewall machine after nearly
two minutes and eatinh 5 my RAM which is 10% of the whole system
there is *nothing* running expect a socket activated sshd and you hardly
get a simpler and smaller setup
[root@firewall:~]$ pstree
systemd─┬─2*[agetty]
├─dbus-broker-lau───dbus-broker
├─sshd───sshd───bash───pstree
├─systemd───(sd-pam)
├─systemd-journal
├─systemd-logind
├─systemd-udevd
├─systemd-userdbd───3*[systemd-userwor]
├─ulogd
├─vmtoolsd───{vmtoolsd}
└─vnstatd
[root@firewall:~]$ systemctl status systemd-userdbd.service
● systemd-userdbd.service - User Database Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service;
static; vendor preset: disabled)
Active: active (running) since Fri 2020-09-04 18:10:39 CEST; 1min
39s ago
TriggeredBy: ● systemd-userdbd.socket
Docs: man:systemd-userdbd.service(8)
Main PID: 474 (systemd-userdbd)
Status: "Processing requests..."
Tasks: 4 (limit: 991)
Memory: 4.6M
CPU: 60ms
CGroup: /system.slice/systemd-userdbd.service
├─474 /usr/lib/systemd/systemd-userdbd
├─475 systemd-userwork
├─476 systemd-userwork
└─477 systemd-userwork
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-userdbd and other stuff running all the time
Am 04.09.20 um 17:37 schrieb Lennart Poettering: > On Mo, 24.08.20 13:40, Reindl Harald (h.rei...@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@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 root9 2020-05-28 09:06 systemd-homed.service -> >> /dev/null >> lrwxrwxrwx 1 root root9 2020-07-06 17:45 systemd-repart.service -> >> /dev/null >> lrwxrwxrwx 1 root root9 2020-08-06 18:48 systemd-timesyncd.service >> -> /dev/null >> lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.service -> >> /dev/null >> lrwxrwxrwx 1 root root9 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-userdbd and other stuff running all the time
On Mo, 24.08.20 13:40, Reindl Harald (h.rei...@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. 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. 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. > > lrwxrwxrwx 1 root root9 2020-05-28 09:06 systemd-homed.service -> > /dev/null > lrwxrwxrwx 1 root root9 2020-07-06 17:45 systemd-repart.service -> > /dev/null > lrwxrwxrwx 1 root root9 2020-08-06 18:48 systemd-timesyncd.service > -> /dev/null > lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.service -> > /dev/null > lrwxrwxrwx 1 root root9 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. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-userdbd and other stuff running all the time
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 7.4 MB is a lot and i don't see any issue by just mask "systemd-userdbd.service" and "systemd-userdbd.socket" on sever systems at the moment, but who knows how deep the dependencies will become in the future lrwxrwxrwx 1 root root9 2020-05-28 09:06 systemd-homed.service -> /dev/null lrwxrwxrwx 1 root root9 2020-07-06 17:45 systemd-repart.service -> /dev/null lrwxrwxrwx 1 root root9 2020-08-06 18:48 systemd-timesyncd.service -> /dev/null lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.service -> /dev/null lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.socket -> /dev/null [root@srv-rhsoft:~]$ systemctl status systemd-userdbd ● systemd-userdbd.service - User Database Manager Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service; static; vendor preset: disabled) Active: active (running) since Mon 2020-08-24 12:45:34 CEST; 48min ago TriggeredBy: ● systemd-userdbd.socket Docs: man:systemd-userdbd.service(8) Main PID: 719025 (systemd-userdbd) Status: "Processing requests..." Tasks: 4 (limit: 512) Memory: 7.4M CPU: 253ms CGroup: /system.slice/systemd-userdbd.service ├─719025 /usr/lib/systemd/systemd-userdbd ├─725718 systemd-userwork ├─725842 systemd-userwork └─725843 systemd-userwork ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
