Page MenuHomePhabricator

fix /etc/xdg/autostart vs systemd race condition
Open, NormalPublic

Description

TLDR:

How to have a /etc/xdg/autostart/app.desktop service wait for a systemd service?

Long:

qubes-whonix-firewall.service runs enable-firewall and conditionally creates the /var/run/qubes-service/whonix-secure-proxy status file.

/etc/xdg/autostart/qubes-whonixsetup.desktop runs /usr/lib/qubes-whonix/qubes-whonixsetup. Sometimes /etc/xdg/autostart/qubes-whonixsetup.desktop runs faster than qubes-whonix-firewall.service. The status file does not exist at that point, which results in an "This TemplateVM needs a Whonix-Gateway NetVM" error popup.

I would like to avoid some sleep/wait/custom code if there is an existing tool for such purposes.


References:


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

Details

Impact
High

Event Timeline

Patrick created this task.Nov 5 2015, 5:52 PM
Patrick raised the priority of this task from to High.
Patrick updated the task description. (Show Details)
Patrick set Impact to High.
Patrick added subscribers: Patrick, marmarek, nrgaway, HulaHoop.

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

Patrick lowered the priority of this task from High to Normal.Nov 21 2015, 12:29 PM

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

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.

Patrick updated the task description. (Show Details)Jun 16 2016, 1:53 PM
Patrick added projects: systemd, research, enhancement.
Patrick updated the task description. (Show Details)Jun 16 2016, 2:59 PM
Patrick updated the task description. (Show Details)Jun 16 2016, 3:05 PM

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.

Patrick updated the task description. (Show Details)Feb 21 2017, 1:12 AM
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

Patrick updated the task description. (Show Details)Feb 26 2017, 7:00 PM

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

Patrick updated the task description. (Show Details)Feb 28 2017, 2:13 AM
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.