tracker-extract crashes with SIGSYS when upgrading from 20.04 to 22.04
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tracker-miners (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Focal |
Fix Released
|
High
|
Unassigned | ||
ubuntu-release-upgrader (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
Focal |
Invalid
|
High
|
Unassigned |
Bug Description
[Impact]
The crash will prompt users during the ugprade, leaving a relatively bad user experience, compounded by the fact that the issue is marked by apport as "Unreportable" since the exec that crashed has usually been removed during the upgrade by the time the user tries to report it.
[Fix]
The crash is due to the Focal tracker-extract binary being triggered during the upgrade while its dependencies, including glibc have already been switched to their Jammy version, leading to new syscalls being used that the Focal seccomp filter didn't know about, notably fstatat64.
There's an upstream commit addressing this specific issue that has been cherry-picked in both Hirsute and Debian, see
https:/
The fix is just backporting this patch further back to Focal, adding fstatat64 and newfstatat to the allowed-list of the seccomp filter. I consider those two syscalls fairly safe and legitimate.
[Test plan]
- Boot a pristine Focal VM
- Install tracker-extract & tracker-miners from -proposed
- run do-release-upgrade -d
-> continue through the "do you want to continue" prompts
=> If all goes well the upgrade should finish and ask you to reboot
=> Otherwise you'd have a tracker-extract crash during the dist-upgrade phase of the upgrade
[Regression potential]
Messing with the seccomp filter could lead to the filter being made either too restrictive, making tracker-extract crash whenever called, or too permissive, weakening the sandboxing for this binary. That latter possibility is IMO more worrisome given the purpose of the package.
[Original report]
When upgrading Ubuntu Desktop from 20.04 to 22.04, there's often (pretty much always) a crash from tracker-extract, as described in the following error report:
https:/
The crash occurs during the upgrade, which means it's fairly hard to investigate exactly what's going on as apport fails to extract a stack trace, the binaries being overwritten during the upgrade.
However, the crash occurs because of a unhandled SIGSYS, meaning a seccomp filter issue. I've tried backporting this patch fixing a similar issue:
https:/
but it doesn't apply, likely due to the code having diverged too much since.
My proposal is thus to disable tracker-extract during upgrade, including in all user sessions. I'm assuming that the new version will be enabled automatically as its unit file changed name anyway.
Changed in ubuntu-release-upgrader (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | added: fr-2595 |
affects: | tracker (Ubuntu) → tracker-miners (Ubuntu) |
description: | updated |
description: | updated |
tags: | added: patch |
Changed in tracker-miners (Ubuntu Focal): | |
status: | Triaged → Fix Committed |
Changed in ubuntu-release-upgrader (Ubuntu): | |
status: | Triaged → Invalid |
Changed in ubuntu-release-upgrader (Ubuntu Focal): | |
status: | Triaged → Invalid |
I tried to produce a usable backtrace by copying the crash file back to a VM that were in the state before the upgrade, but the backtrace there has GDB warnings: Section `.reg-xstate/ $number' in core file too small. I assume that the crash happens when already some package were updated.
What I saw the the journal log: dbus-daemon[813]: Unknown group "power" in message bus configuration file
You can try to create the GDB backtrace directly after the crash. Modify ExecStart in systemd/ user/tracker- extract. service to:
/usr/lib/
ExecStart= /usr/bin/ gdb --batch --ex run --ex bt /usr/libexec/ tracker- extract