Bug#1109273: mutter: intermittent test failure in service-channel test: The name org.gnome.Mutter.ServiceChannel was not provided by any .service files

[Simon McVittie]

Source: mutter
Version: 48.4-2
Severity: important
Tags: ftbfs unreproducible
User: debian-ci at lists.debian.org
Usertags: flaky

In one autopkgtest on ppc64el, 
https://ci.debian.net/packages/m/mutter/testing/ppc64el/62167381/ we can 
see this failure:

>634s # Running test: mutter-16/service-channel.test
>636s # Executing: mutter-16/service-channel.test
>638s # FAIL: mutter-16/service-channel.test (Child process exited with code 250)
>638s not ok - mutter-16/service-channel.test
[... lots more results ...]
>652s # SUMMARY: total=34; passed=31; skipped=0; failed=3; user=54.7s; system=14.5s; maxrss=1146276
[... 2 unrelated failures, out-of-scope here ...]
>652s # FAIL: mutter-16/service-channel.test (Child process exited with code 250)

For further details of that failure we have to look in the 
$AUTOPKGTEST_ARTIFACTS (artifacts.tar.gz on ci.debian.net) and read 
artifacts/mutter-16_service-channel.test.txt, quoted in full here:

>Setup HOME as /tmp/mutter-testroot-yaqls9wt/home
>Setup TMPDIR as /tmp/mutter-testroot-yaqls9wt/tmpdir
>Setup XDG_CACHE_HOME as /tmp/mutter-testroot-yaqls9wt/xdg_cache_home
>Setup XDG_CONFIG_HOME as /tmp/mutter-testroot-yaqls9wt/xdg_config_home
>Setup XDG_DATA_HOME as /tmp/mutter-testroot-yaqls9wt/xdg_data_home
>Setup XDG_RUNTIME_DIR as /tmp/mutter-testroot-yaqls9wt/xdg_runtime_dir
>Starting D-Bus daemons (session & system)...
>Binding /tmp/mutter-testroot-yaqls9wt/xdg_runtime_dir/pipewire-0 for socket activation
>Binding /tmp/mutter-testroot-yaqls9wt/xdg_runtime_dir/pipewire-0-manager for socket activation
>Launching required services...
>Starting mocked services...
>ERROR:dbus.proxies:Introspect error on :1.1:/org/freedesktop/login1/session/dummy: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/login1/session/dummy'.
>Running test case...
>Process ['/usr/libexec/installed-tests/mutter-16/mutter-service-channel'] started with pid 8117
>TAP version 14
># random seed: R02S38e0192555d7fd6babbdacaae03fd09f
># GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation memory (GMemorySettingsBackend) for ‘gsettings-backend’
># GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used after threads are created
># libmutter-MESSAGE: Running Mutter Test (using mutter 48.4) as a Wayland display server
># libmutter-MESSAGE: Created surfaceless renderer without GPU
># GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
># libmutter-DEBUG: WL: Unable to initialize wl_eglstream_controller.
># libmutter-MESSAGE: Using Wayland display name 'mutter-test-display'
># libmutter-MESSAGE: Added virtual monitor Meta-0
>1..1
># Start of service-channel tests
>
>** (process:8160): ERROR **: 09:17:15.887: Failed to open Wayland service connection: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.Mutter.ServiceChannel was not provided by any .service files
># libmutter-INFO: Acquired name org.gnome.Mutter.InputMapping
># libmutter-DEBUG: Acquired name org.freedesktop.a11y.Manager
>**
>mutter-service-channel-test:ERROR:../src/tests/meta-wayland-test-utils.c:59:wayland_test_client_finished: 'g_subprocess_get_successful (wayland_test_client->subprocess)' should be TRUE
>not ok /service-channel/wayland - mutter-service-channel-test:ERROR:../src/tests/meta-wayland-test-utils.c:59:wayland_test_client_finished: 'g_subprocess_get_successful (wayland_test_client->subprocess)' should be TRUE
>Bail out!
>Closing PipeWire socket...
>Terminating services...

I suspect that this test may have started some background process that 
ought to become the owner of org.gnome.Mutter.ServiceChannel, but then 
immediately proceeded with testing without waiting for the name to be 
owned, leading to a race condition: if the owner of 
org.gnome.Mutter.ServiceChannel wins the race then the test passes, but 
if the client wins the race then the test fails.

I only observed this in autopkgtest results, but it could in principle 
affect build-time tests too, so I've added the ftbfs tag.

    smcv