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 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.

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.

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.