https://i.imgur.com/34IcvFD.jpeg
Why do i have these “waiting” entries in my system? I have tried google, and i guess they are the result of the “systemd-nsresourced.service” and “systemd-userdbd.service” running in the background (i checked and they are indeed running). I also have “sockets” enabled for these two.
Now it is highly likely these services come default enabled with the manjaro installation. I did not enable them myself. So am i OK with this? Do i need these services?
A little reading from some a hasty web search I just did:
https://bbs.archlinux.org/viewtopic.php?id=294992
https://man.archlinux.org/man/core/systemd/systemd-userdbd.8.en
https://systemd.io/USER_RECORD/
(which says that systemd-userdbd is used by logind)
https://man.archlinux.org/man/core/systemd/systemd-nsresourced.8.en
Both seem to be related to user/group lookups on a system. From the man pages above.
systemd-userdbd:
systemd-userdbd is a system service that multiplexes user/group lookups to all local services that provide JSON user/group record definitions to the system. In addition it synthesizes JSON user/group records from classic UNIX/glibc NSS user/group records in order to provide full backwards compatibility. It may also pick up statically defined JSON user/group records from files in /etc/userdb/, /run/userdb/, /run/host/userdb/ and /usr/lib/userdb/ with the “.user” extension.
Most of systemd-userdbd’s functionality is accessible through the userdbctl(1) command.
The user and group records this service provides access to follow the JSON User Records[1] and JSON Group Record[2] definitions. This service implements the User/Group Record Lookup API via Varlink[3], and multiplexes access other services implementing this API, too. It is thus both server and client of this API.
This service provides three distinct Varlink[4] services: io.systemd.Multiplexer provides a single, unified API for querying JSON user and group records. Internally it talks to all other user/group record services running on the system in parallel and forwards any information discovered. This simplifies clients substantially since they need to talk to a single service only instead of all of them in parallel. io.systemd.NameServiceSwitch provides compatibility with classic UNIX/glibc NSS user records, i.e. converts struct passwd and struct group records as acquired with APIs such as getpwnam(1) to JSON user/group records, thus hiding the differences between the services as much as possible. io.systemd.DropIn makes JSON user/group records from the aforementioned drop-in directories available.
systemd-nsresourced:
systemd-nsresourced is a system service that permits transient delegation of a UID/GID range to a user namespace (see user_namespaces(7)) allocated by a client, via a Varlink IPC API.
Unprivileged clients may allocate a user namespace, and then request a UID/GID range to be assigned to it via this service. The user namespace may then be used to run containers and other sandboxes, and/or apply it to an id-mapped mount.
Allocations of UIDs/GIDs this way are transient: when a user namespace goes away, its UID/GID range is returned to the pool of available ranges. In order to ensure that clients cannot gain persistency in their transient UID/GID range a BPF-LSM based policy is enforced that ensures that user namespaces set up this way can only write to file systems they allocate themselves or that are explicitly allowlisted via systemd-nsresourced.
systemd-nsresourced automatically ensures that any registered UID ranges show up in the system’s NSS database via the User/Group Record Lookup API via Varlink[1].
Currently, only UID/GID ranges consisting of either exactly 1 or exactly 65536 UIDs/GIDs can be registered with this service. Moreover, UIDs and GIDs are always allocated together, and symmetrically.
The service provides API calls to allowlist mounts (referenced via their mount file descriptors as per Linux fsmount() API), to pass ownership of a cgroup subtree to the user namespace and to delegate a virtual Ethernet device pair to the user namespace. When used in combination this is sufficient to implement fully unprivileged container environments, as implemented by systemd-nspawn(1), fully unprivileged RootImage= (see systemd.exec(5)) or fully unprivileged disk image tools such as systemd-dissect(1).
This service provides one Varlink[2] service: io.systemd.NamespaceResource allows registering user namespaces, and assign mounts, cgroups and network interfaces to it.
systemd-userdbd & systemd-nsresourced are part of the systemd package, so you probably don’t want to mess with them as it could risk breaking your system. You can check their status with the following command:
systemctl status systemd-userdbd systemd-userdbd.socket systemd-nsresourced systemd-nsresourced.socket
Both of those services are socket activated, so the .service should show as disabled & the .socket as enabled, as per the output from my machine:
systemctl status systemd-userdbd systemd-userdbd.socket systemd-nsresourced systemd-nsresourced.socket
○ systemd-userdbd.service - User Database Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.service; indirect; preset: disabled)
Active: inactive (dead)
TriggeredBy: ○ systemd-userdbd.socket
Docs: man:systemd-userdbd.service(8)
○ systemd-userdbd.socket - User Database Manager Socket
Loaded: loaded (/usr/lib/systemd/system/systemd-userdbd.socket; disabled; preset: enabled)
Active: inactive (dead)
Triggers: ● systemd-userdbd.service
Docs: man:systemd-userdbd.service(8)
Listen: /run/systemd/userdb/io.systemd.Multiplexer (Stream)
○ systemd-nsresourced.service - Namespace Resource Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-nsresourced.service; indirect; preset: disabled)
Active: inactive (dead)
TriggeredBy: ○ systemd-nsresourced.socket
Docs: man:systemd-nsresourced.service(8)
FD Store: 0 (limit: 4096)
○ systemd-nsresourced.socket - Namespace Resource Manager Socket
Loaded: loaded (/usr/lib/systemd/system/systemd-nsresourced.socket; disabled; preset: enabled)
Active: inactive (dead)
Triggers: ● systemd-nsresourced.service
Docs: man:systemd-nsresourced.service(8)
Listen: /run/systemd/io.systemd.NamespaceResource (Stream)
Thanks for looking into it. I have actually disabled both services together with their sockets. I notice no difference in the way my system is operating. The “waiting” messages in htop is gone. I’d like to think that they were useless services in my case. If anything comes up, i can re-enable them but i doubt it.
Annex: Something interesting i just realized. I also have the “systemd-homed.service” enabled.
You're using systemd-homed, which is not common unless you're deliberately using homed-based user management (.home directories managed by systemd).
Am I? Is this a manjaro thing?
So i also disabled that. I am guessing manjaro arm has these enabled by default for compatibility or to serve to more use cases. So maybe for a simple desktop system, these aren’t necessary. I remember back in my windows days that the first thing we do after a fresh install was disabling all those unncecessary windows services 
So some things don’t change ha?
Just to confirm, is your installation Manjaro ARM?
It is the “unstable” Manjaro ARM for RPI5.
In future, please post your support requests in the ARM section of the forums. I have been providing advice assuming you are using an X86-64 (Intel/AMD) system.
I just moved it and added the (hopefully appropriate) tags. 
Sorry.
This problem could have easily been avoided if you had added your system details to your user profile. The first thing I (and many others here) do when looking at a support request is click on the member’s avatar to (hopefully) see what type of system they are running, and the branch (Unstable, Testing, Stable) they are on.
Please update your user profile by visiting this page: Forum Profile Preferences
Also, as is usually requested for Support topics, the output of
inxi -zv8
… formatted to proper Forum requirements —
i.e. adding three backticks ``` (or three tildes ~~~) on their own lines before and after the pasted text;
… or, maybe easier:
highlighting the pasted text and clicking the </> button at the top of the reply window.
This means we’ll get current System Information.