Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Offline update Trigger() can emit PropertiesChanged for the same event twice, maybe since 1.4.0

Open
  • Is something wrong?
#1,020 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
66/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c
Domain
api, backend

Research direction

Start in src/pk-engine.c: read the Trigger/TriggerUpgrade handler, the pk_engine_emit_offline_property_changed calls, and the async completion callback pk_engine_offline_helper_cb, plus commit 0e7ca06 for the behavior change. Reproduce with gdbus monitor on the system bus while running an offline update to confirm whether two overlapping Trigger() calls or one call causes the duplicate PropertiesChanged emissions. Done looks like a Trigger() that is already triggered (or completed by a concurrent call) emits no duplicate property changes, verified by a single set of signals per logical trigger.

Written by the indexing model from the issue text.

Description

Not 100% sure this is a real bug or just me misreading something, but figured I'd flag it since I've got decent evidence pointing at it.

I was chasing a KDE Plasma/Discover bug (Discover's "Reboot after update" sometimes not actually rebooting - see bugs.kde.org #525911 if you want the full backstory) and traced it down to Discover firing a D-Bus call twice for one logical action. Fixed that on the KDE side, but while digging I noticed the actual duplicate signal seems to originate from PackageKit itself, not Discover.

I stuck a gdbus monitor on the system bus during a normal "install updates, reboot after update" run and got this (this was just a normal update+reboot):

PropertiesChanged (Offline, {'TriggerAction': <'reboot'>}, []) 
PropertiesChanged (Offline, {'UpdateTriggered': <true>}, []) 
PropertiesChanged (Offline, {'UpgradeTriggered': <false>}, []) 
PropertiesChanged (Offline, {}, ['PreparedUpgrade']) 
PropertiesChanged (Offline, {'TriggerAction': <'reboot'>}, [])     <- again 
PropertiesChanged (Offline, {'UpdateTriggered': <true>}, [])       <- again 
PropertiesChanged (Offline, {'UpgradeTriggered': <false>}, [])     <- again 
PropertiesChanged (Offline, {}, ['PreparedUpgrade'])               <- again

Went digging in src/pk-engine.c and I think I see why. There's a commit, 0e7ca06 ("Never let a Trigger call disarm or replace an armed trigger"), that landed right before 1.4.0. Before it, the "already triggered, just update the action" fast path in the Trigger/TriggerUpgrade handler was silent - no signal at all:

if (pk_engine_offline_is_triggered(...)) {
    if (pk_offline_auth_set_action(action, &error))
        g_dbus_method_invocation_return_value(invocation, NULL);
    // nothing emitted
    return;
}

After that commit, same path now emits a property change:

  if (pk_engine_offline_is_triggered(...)) {
      if (!pk_offline_auth_set_action(action, &error)) { ... }
      pk_engine_emit_offline_property_changed(engine, "TriggerAction", ...); // new
      g_dbus_method_invocation_return_value(invocation, NULL);
      return;
  }

So if a second Trigger() call comes in after the first already finished, it used to be a true no-op. Now it isn't - it fires a signal it didn't before. On top of that, the async completion callback (pk_engine_offline_helper_cb) checks whether the kind of polkit action needed has changed while it was waiting on auth, but doesn't check whether the trigger was already completed by another call in the meantime. So if two Trigger() calls genuinely overlap while both are still waiting on polkit, they could both fall through and both do the full auth-then-emit-everything dance.

Timing-wise this lines up suspiciously well too - on the machine where I caught this, PackageKit got bumped to 1.4.0 on the 15th, and the first time I actually saw the downstream KDE bug was the 18th. Not exactly a smoking gun, but a pretty tight window.

What I haven't nailed down: who's actually calling Trigger() twice. On the Discover side there's only one call site (PackageKitUpdater::finished()), called once per transaction, so if it really is two overlapping calls, the second one isn't obviously coming from Discover itself - could be something else in the offline-update chain. Also can't fully rule out that it's just a single call somehow causing the emission helper to run twice internally, rather than two separate D-Bus calls. Haven't had a chance to dig further on that part.

Anyway - figured this was worth a look even if I can't pin down the exact "who" yet. Happy to grab more targeted D-Bus captures if that'd help, the setup was easy enough to throw together.

Running PackageKit 1.4.0-1 on Fedora 44, dnf5 backend, if that matters.

The currently open KDE PR on plasma-workspace, blocks 2nd call from executing so it doesn't break the full restart anymore.

Dominant language
C
Stars
360
Forks
196
Avg merge
1d 12h
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from PackageKit/PackageKit

All issues in PackageKit/PackageKit

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.