dbus-daemon test: Allow much longer for pending fd timeout
authorSimon McVittie <smcv@collabora.com>
Tue, 23 Oct 2018 10:43:23 +0000 (11:43 +0100)
committerSimon McVittie <smcv@collabora.com>
Fri, 16 Nov 2018 15:09:06 +0000 (15:09 +0000)
The timeout we're using here is 0.5s (500ms), but the actual time taken
is unbounded, because the OS scheduler might not schedule our process
for an arbitrary length of time after we become runnable.

We previously allowed up to 1 second, but in the CI jobs for dbus!9
and dbus!18 we've seen this take up to 3.4 seconds (presumably
because other tests, or other jobs running on the same shared
infrastructure, starved this process). Allow up to 10 seconds to guard
against spurious failures.

The timeout used in the production system.conf is 150 seconds (2½
minutes), and we're only using the shorter 500ms timeout here to make
the test complete more quickly, so ±10 seconds is relatively
insignificant: the main thing is that it's finite.

Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 20e6eb7cd1f9c2ad941bd62c8f1f71712377a96e)

test/dbus-daemon.c

index 311cc08..7d3bb4b 100644 (file)
@@ -1045,9 +1045,13 @@ test_pending_fd_timeout (Fixture *f,
       test_progress ('.');
       test_main_context_iterate (f->ctx, TRUE);
 
-      /* It should take no longer than 500ms to get disconnected. We'll
-       * be generous and allow 1000ms. */
-      g_assert_cmpint (g_get_monotonic_time (), <=, start + G_USEC_PER_SEC);
+      /* It should take 0.5s to get disconnected, as configured in
+       * valid-config-files/pending-fd-timeout.conf; but this test
+       * might get starved by other processes running in parallel
+       * (particularly on shared CI systems), so we have to be a lot
+       * more generous. Allow up to 10 seconds. */
+      g_assert_cmpint (g_get_monotonic_time (), <=,
+                       start + (10 * G_USEC_PER_SEC));
     }
 
   g_object_unref (socket);