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.