The configuration import subsystem creates several services at the system level for each user.
user@name: user target
An umbrella target named user@name encompasses all of the other services.
Starting the target auto-starts all of the other services, if they are enabled.
user-runtime@name: per-user runtime area
This service creates (on startup) and destroys (on shutdown) the per-user runtime area for the user that is in /run/user/name.
It wants and is ordered after any mount service for /run/user that may exist.
It wants and is ordered before any mount service for /run/user/name that may exist.
The import subsystem does not generate or supply such mount services.
user-services@name: per-user manager
This service runs an instance of per-user-manager as the user.
This in turn runs an instance of service-manager that manages the per-user services.
user-dbus-daemon@name: per-user Desktop Bus broker
This service runs an instance of dbus-daemon as the user.
It uses a private configuration file from the service definition that ensures that dbus-daemon-launch-helper is used to demand-start servers.
The socket that this broker listens on is in the conventional place at /run/user/name/bus.
This is an old way of starting up a per-user broker service. It is usually not used in favour of a broker service that is run by the per-user service manager and thus directly configurable by the user. The twain should not be used simultaneously.
If you want a user fred's per-user service management to be auto-started started at bootstrap, simply enable either the user-services@fred service specifically, or enable the user@fred target as a whole.
To have user fred's per-user service management start when fred first logs in, have system-control start user@fred (run by the superuser, of course) as part of the login process.
Users do not have to run any per-user services at all, of course.