How to have an /etc/xdg/autostart/app.desktop service wait for a (systemd) service?
http://unix.stackexchange.com/questions/241058/how-to-have-an-etc-xdg-autostart-app-desktop-service-wait-for-a-systemd-servi

The easiest (but maybe not the most efficient) way would be adding
Before= ordering in service. In Qubes case, it would be
Before=qubes-gui-agent.service.

That's alright as a workaround for Whonix 12. Let's see if there is a more efficient solution.

qubes-whonix-firewall: Preventing race condition with Qubes Whonix Setup.:
https://github.com/Whonix/qubes-whonix/commit/790679d88bba74a587dbaedaae1ea166dcdf0989

Asked also on the pkg-systemd-maintainers mailing list:
How to have an /etc/xdg/autostart/app.desktop service wait for a (systemd) service?
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-November/009434.html

I didn't figure out how to use per-user systemd --user services in plain Debian (let alone in Qubes Debian template).

document how to use per-user systemd --user services:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820111

Seems explained here:

https://wiki.archlinux.org/index.php/Systemd/User

I've found that before. Doesn't help.

Status...
WIP: https://github.com/adrelanos/qubes-whonix/tree/T424
Waiting for instructions on how to use per-user systemd --user services in Debian.

Cannot be implemented now therefore. Rechecking when porting to Debian stretch.

One step closer.

By Debian stretch default, there are some default systemd user unit files in /usr/lib/systemd/user/.

/usr/lib/systemd/user/mytest.service:

[Unit]
Description=mytest

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

[Install]
WantedBy=default.target

systemctl --user enable mytest

Worked for me.

Created symlink /home/user/.config/systemd/user/default.target.wants/mytest.service → /usr/lib/systemd/user/mytest.service.

I haven't figured out yet how to cleanly (or uncleanly) enable systemd user services using Debian packaging. sudo -u user systemctl --user enable mytest will probably not work (apt-get somehow does not like sudo -u user anymore since Debian stretch), and that would not be a clean solution either.

In T424#12408, @Patrick wrote:

I haven't figured out yet how to cleanly (or uncleanly) enable systemd user services using Debian packaging. sudo -u user systemctl --user enable mytest will probably not work (apt-get somehow does not like sudo -u user anymore since Debian stretch), and that would not be a clean solution either.

Existing Debian feature request dh-systemd: Please support systemd user services:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678

As per

Existing Debian feature request dh-systemd: Please support systemd user services:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678

a symlink /usr/lib/systemd/user/default.target.wants/qubes-whonixsetup.service using debian/qubes-whonix.links might be a workable acceptable solution for strretch until Debian feature 764678 gets implemented.

https://github.com/Whonix/qubes-whonix/commit/170cd1dbcee09119e171b7d930d4be7f5f3e14b3

That worked. Somewhat. Now I need to figure out if there is a sane way to sort out the environment variables.

Feb 21 03:06:56 host qubes-whonixsetup[1104]: kdesudo: cannot connect to X server :0

A systemd --user instance knows nothing about the systemd --system instance. I.e. a systemd --user instance cannot reference After=some-system.service. Source:

https://lists.freedesktop.org/archives/systemd-devel/2017-February/038361.html

So we cannot use qubes-whonixsetup.service After=qubes-gui-agent.service.

systemd feature request - systemd --user instance ability to reference systemd --system services with After= etc.:
https://github.com/systemd/systemd/issues/5462

Asked about how to set the environment variables and got some answers:
https://lists.freedesktop.org/archives/systemd-devel/2017-February/038365.html

Perhaps ExecStartPre=systemctl --user import-environment would do.

However, that is currently not possible.

Environment variable QUBES_KEYMAP breaks systemctl --user import-environment.

systemd bug report - systemctl --user import-environment fails on complex environment variable with Failed to import environment: Invalid environment assignments:
https://github.com/systemd/systemd/issues/5481

In T424#12530, @Patrick wrote:

A systemd --user instance knows nothing about the systemd --system instance. I.e. a systemd --user instance cannot reference After=some-system.service. Source:

https://lists.freedesktop.org/archives/systemd-devel/2017-February/038361.html

So we cannot use qubes-whonixsetup.service After=qubes-gui-agent.service.

systemd feature request - systemd --user instance ability to reference systemd --system services with After= etc.:
https://github.com/systemd/systemd/issues/5462

/lib/systemd/system/user@.service does ExecStart=-/lib/systemd/systemd --user. In theory we could add a systemd drop-in adding: After=qubes-gui-agent.service but that looks like an awful hack.

ExecStartPre=systemctl --user import-environment also looks like an awful hack. Doing something as the distribution that should really be only done by the user.

Given all these issues referenced above, I don't think systemd is ready to replace /etc/xdg/autostart. We'll probably need to wait until the X (or by that time perhaps wayland) session gets started by the systemctl --user session.

Rechecking the status of systemd's capabilities at a later release.