Those processes are server processes and they are supposed to always run in the background. In that way they are ready to be accessed by client software immediately. For why they are root: often but not always servers need elevated privileges, e.g. to open ports below 1024 or read restricted files.
post
systemctl list-dependencies --reverse anydesk should show if any other services depend on them
Most probably those services are started because some other service depends on them.
After running systemctl disable someservice the service someservice is not "disabled" in the sense that it can't be started, it merely isn't started automatically at startup. If you want to make a service not startable, use systemctl mask (or, you know, uninstall/delete it?).
systemctl list-dependencies --reverse mysql.service should list the services that depend on mysql.service.
This is where the server/client concept comes from. Some server software runs in the background and wait for access from an external client software. Then it works on the server and produces and output for the client. This way the entire server does not need to start run and stop for every single request. I mean you don't start and close every time you click on a new link on the website, right? So your PC runs all the time. And that's similar to how MySQL operates. It starts a server in the background and then waits for any application to use it. So this is totally normal.
Now because lot of people don't want to start the server process "by hand", they put it in autostart, so it starts with your system. If you don't want it to autostart, maybe there is a way of configuring it so you have to start it manually each time you want to use it. But I cannot assist with that help, just wanted to explain why that is on a high level.
Whether a system(d) service is activated by default after you install a package is a distro-specific choice. I know Debian and derivatives do, so it will be started at the next reboot; while Arch and derivatives don't, requiring an explicit systemctl enable [--now] something.service to run it. The devs of the distro try to pick what they think their userbase wants and after the initial decision is taken it's not a behaviour that can be changed lightly.
Regarding running as root, sometimes it's just the default configuration that can be changed to a dedicated user, other times it's required by the privileges they use (e.g. if they need to open a port below 1024)
systemctl list-unit-files --state=enabled to check everything enabled that you might want to disable
as for running as root, AFAIK all systemd services run as root, unless they're defined at the user-level; but IME setting services at the user level usually means a more involved setup to make sure PATH and env vars are correct.
Well behaved services would usually run on a special user that exists just for that service. Either systemd would run the service using the specified user or the service would start as root to do privileged operations like opening specific ports and then run subprocesses as the more limited user.
Systemd can also create a temporary user, with DynamicUser. But I so very rarely see that being used.
the service would start as root to do privileged operations like opening specific ports
You can also add the CAP_NET_BIND_SERVICE capability to do this without root.
IMO, there's usually no reason to use root in a systemd service, it's just ignorant developers.
all 9 comments