** Changed in: gnome-control-center (Ubuntu)
Status: Invalid => In Progress
** Description changed:
On stonking with gnome-control-center 1:51.0-1ubuntu1 and
whoopsie-preferences 23build4, the journal shows whoopsie-preferences
starting,
acquiring com.ubuntu.WhoopsiePreferences, then exiting cleanly, once a minute,
forever:
- systemd[1]: Started dbus-:[email protected].
- systemd[1]: dbus-:[email protected]:
Deactivated successfully.
- whoopsie-preferences[3607]: Acquired the name:
com.ubuntu.WhoopsiePreferences
+ systemd[1]: Started dbus-:[email protected].
+ systemd[1]: dbus-:[email protected]:
Deactivated successfully.
+ whoopsie-preferences[3607]: Acquired the name:
com.ubuntu.WhoopsiePreferences
It looks like a crash loop but is not: "Deactivated successfully" is a clean
exit, the @N suffix is the per-boot D-Bus activation serial. On my machine
this
- had been running for ~a day: roughly 1440 root process spawns per day, purely
- to keep a settings cache warm for a panel nobody has open.
-
- Two behaviours, each reasonable on its own, loop against each other:
-
- 1. whoopsie-preferences quits its main loop 60 s after its last activity
- (src/whoopsie-preferences.c:462, increase_shutdown_timeout() at :252).
- Deliberate: it should not idle-resident.
-
- 2. gnome-control-center's Ubuntu Telemetry page (the whoopsie support added by
- d/p/u/diagnostics-Add-Whoopsie-support.patch, carried over to
- cc-telemetry-page.c by the telemetry patch) connects a handler to the
- proxy's notify::g-name-owner. Whenever the name loses its owner it calls
- whoopsie_preferences_call_get_identifier() fire-and-forget. The comment in
- the patch says it outright: "Trigger the service to start again, as it has
- just been stopped by a timeout".
-
- So while any gnome-control-center process is alive - including the headless
- --gapplication-service instance with no window open - the pair ping-pongs:
- g-c-c starts the service, the service quits 60 s later, g-c-c starts it again.
-
- Evidence that g-c-c is the driver (SIGSTOP the resident
- gnome-control-center process): the next 60 s tick shows the service
- deactivating but no new activation; on SIGCONT an activation fires
- immediately, off the usual cadence. strace on a live whoopsie-preferences
- instance over its last 20 s of life shows zero received D-Bus messages, i.e.
- nothing ever actually talks to the service after activation.
-
- The whoopsie daemon itself is not involved: whoopsie.service is static and
- whoopsie.path disabled, so only whoopsie-preferences churns.
-
- Proposed fix, verified locally on stonking (patch attached, built and
- installed as 1:51.0-1ubuntu2+local):
-
- - create the whoopsie proxy with G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START, so a
- page that is never shown activates nothing at construction time;
- - gate whoopsie_bus_owner_changed() on gtk_widget_get_mapped(): a headless
- service instance no longer re-activates anything, and when the owner
- appears while the page is shown, sync the row;
- - add a map handler: when the user actually opens the Telemetry page, sync
- the row if the service is owned, otherwise activate it explicitly via
- org.freedesktop.DBus.StartServiceByName (method calls are refused on
- unowned proxies created with DO_NOT_AUTO_START, so this must be explicit);
- - leave the combo row insensitive until the whoopsie state is actually
- known.
-
- After the fix: whoopsie-preferences is activated only while the Telemetry page
- is on screen (the visible page keeps reactivating it on its idle exits, which
- is the original keep-alive intent, bounded by visibility). A resident g-c-c
- with the page not mapped causes zero activations; verified with
- SIGSTOP/SIGCONT, a 2m15s observation window, and an overnight soak.
-
- Side note for the whoopsie-preferences side of this design: its idle exit
- fires while clients still hold proxies on the bus. Should whoopsie-preferences
- keep running while there are clients instead? That would make this class of
- reactivation loops moot, but it is a design question for the whoopsie
- maintainers rather than a patch I can propose here.
+ had been running for ~a day: roughly 1440 root process spawns per day, purely
to keep a settings cache warm for a panel nobody has open.
** Description changed:
On stonking with gnome-control-center 1:51.0-1ubuntu1 and
whoopsie-preferences 23build4, the journal shows whoopsie-preferences
starting,
acquiring com.ubuntu.WhoopsiePreferences, then exiting cleanly, once a minute,
forever:
systemd[1]: Started dbus-:[email protected].
systemd[1]: dbus-:[email protected]:
Deactivated successfully.
whoopsie-preferences[3607]: Acquired the name:
com.ubuntu.WhoopsiePreferences
It looks like a crash loop but is not: "Deactivated successfully" is a clean
exit, the @N suffix is the per-boot D-Bus activation serial. On my machine
this
had been running for ~a day: roughly 1440 root process spawns per day, purely
to keep a settings cache warm for a panel nobody has open.
+
+ The right way to fix this is to add a Hold/Release pattern to whoopsie-
+ preferences so that it can keep track of active clients.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167557
Title:
gnome-control-center re-activates whoopsie-preferences every 60 s
(journal noise, ~1440 root spawns/day)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/2167557/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
