/run/lock/power_override/fwupd.lock occasionally left on ChromeOS

[rcyeh]

Describe the bug

On ChromeOS, fwupd 1.9.7 may crash when updating Logitech Rally Bar Mini to 1.10.369. On ChromeOS, fwupd may integrate with powerd, and after the crash, leaves a lockfile /run/lock/power_override/fwupd.lock for days, long after the fwupd update process is likely no longer running.

(Google internal bug reference: b/328243112)

Steps to Reproduce

Across the fleet of Chromebox-for-Meetings, we have seen multiple devices with a Logitech Rally Bar Mini, attempting and failing to update firmware to 1.10.369, and then logging: INFO powerd: [daemon.cc(1812)] Postponing shutdown for lockfile(s): /run/lock/power_override/fwupd.lock.

This has occurred since R114-15437.59.32. It does not happen on every Logitech Rally Bar Mini. We have not reproduced this behavior in a controlled/developer environment.

Expected behavior

In most cases, the Logitech Rally Bar Mini firmware update to 1.10.369 succeeds, and no /run/lock/power_override/fwupd.lock lockfile is left behind.

If the update fails, we would like fwupd to tell powerd to clean up the lock file.

fwupd version information

1.9.7

fwupdmgr --version
compile   org.freedesktop.fwupd         1.9.7
compile   com.hughsie.libxmlb           0.3.11
compile   com.hughsie.libjcat           0.1.8
compile   org.freedesktop.gusb          0.4.8
runtime   org.freedesktop.gusb          0.4.8
runtime   org.kernel                    4.19.297-15324-ga283848f9970
runtime   org.freedesktop.fwupd         1.9.7

Please note how you installed it (apt, dnf, pacman, source, etc):

On ChromeOS, I believe fwupd is installed as a gentoo package.

**fwupd device information**

Please provide the output of the fwupd devices recognized in your system.

fwupdmgr get-devices --show-all-devices

Additional questions

• Operating system and version: ChromeOS R114-15437.59.32
• Have you tried rebooting? Rebooting will clear the lock file. Sometimes on reboot, the firmware update succeeds.
• Is this a regression? Unknown

[hughsie]

fwupd 1.9.7 may crash

I think that's priority #1 to fix! Do you happen to have any kind of backtrace or daemon -vv log?

If the update fails, we would like fwupd to tell powerd to clean up the lock file.

I think on update failure we actually do try to do just that; see https://github.com/fwupd/fwupd/blob/main/src/fu-engine.c#L3365

Although if fwupd actually crashed we'd never get a chance to do the cleanup. I wonder if that's something we could do in the upstart script, e.g. like systemd can do (e.g. OnFailure or ExecStopPost).

Another alternative {workaround?} would be to delete the lockfile when starting fwupd -- on the assumption we're actually auto-starting fwupd after the failed update.

[rcyeh]

Unfortunately, our current systems in the field do not upload the fwupd.log file, and I have not reproduced this in an environment where I can get verbose logs.

Thanks for the suggestion to add a cleanup to the upstart script --- I will do that! (The lockfile was preventing a system reboot.)

[hughsie]

powerd: [daemon.cc(1812)] Postponing shutdown for lockfile(s): /run/lock/power_override/fwupd.lock

I also think that powerd should also read the contents of this file and check of the PID (the integer in the file) is still alive...