In addition to setting up system-level services for each user the configuration import subsystem sets up a whole load of service bundles for each user, to be managed by that user's personal instance of service-manager.
These service bundles live in the user's service bundles directory in the user's home directory.
The services fall into one of three main groups: logging, non-Desktop Bus, and Desktop Bus.
There are three major logging services.
simple-servers-log/var/log/user/username/simple-servers/.
socket-servers-log/var/log/user/username/socket-servers/.
dbus-servers-log/var/log/user/username/dbus-servers/.
Non-Desktop Bus services are either straightforward simple services or services that listen on sockets. They do not require the per-user Desktop Bus broker to be running. Examples are:
emacs--fg-daemon mode only).
urxvturxvtd dæmon.
gpg-agent/run/user/username/gnupg/S.gpg-agent.
These services are not set up with a DBUS_SESSION_BUS_ADDRESS environment variable.
Desktop Bus services require the per-user Desktop Bus broker to be running.
This can either be running as the system-level user-dbus-daemon@username service or as a user-level dbus-daemon service.
The latter requires that the full per-user service manager be running; and cannot be used until the per-user service manager is started.
They also need to know how to talk to it.
So the configuration import subsystem chain loads them from the userenv program with the --set-dbus option, setting an environment variable that gives the address (in path= form because no-one understands the runtime= form yet) of the /run/user/name/bus socket.
By convention, a Desktop Bus service is named by a common name by which users refer to it directly (such as gnome-terminal-server), and has an alias pointing to it from its formal Desktop Bus "server" name (such as org.gnome.Terminal).
The alias is used by the Desktop Bus broker when demand-starting the service, because the Desktop Bus broker only knows the formal names of services.
Processes run under per-user service management execute in a dæmon-style context.
They don't have controlling terminals, and (initially) they only have the environment variables set up by the user-services@username service itself, which just runs userenv (which runs userenv-fromenv).
In particular:
They do not have the environment variables that are set up in the users' rc/profile/login scripts for shells. Shells, and thus their rc script mechanisms, are not involved in the running of the per-user service manager instance.
They do not have the environment variables that are set up via the login class records in the users' ~/.login_conf and the /etc/login.conf databases.
Per-user service management does not, conceptually, run within a login session.
Every user-level service is afforded an environment directory in its service definition, in the conventional location that is accessble via the likes of system-control --user print-service-env org.example.Sheila.
Environment variable for services should be configured there.
It is the wrong thing to do to explicitly set up per-user services with TTY or DISPLAY environment variables, and this is the sign of a faulty service program.
Service programs serve a single user that can be logged in multiple times in multiple forms of login session.
They should not require terminal access, and should be capable of connecting to multiple X displays simultaneously and not need an X display in order to start up.
Programs that are known to get this wrong include GNOME Terminal, KDE Notify, GNOME Weather, GNOME Maps, and MATE Notification.
These fail to work if they are not given a DISPLAY environment variable in order to start up in their initial not-a-client-of-any-displays-yet state, where no D-BUS clients have connected to tell them about X displays to make windows on.
This is accounted for in the configuration import subsystem, which sets up a DISPLAY environment variable for each user's gnome-terminal-server, knotify, org.gnome.Weather.Application, org.gnome.Maps and mate-notification-daemon service.
It just sets up DISPLAY as :0 for the service.
You might need to tweak this for unusual X setups.