tpsd: don't use full-blown "udevadm trigger" and "udevadm settle" when it's not necessary
In #19948 (closed) we identified a timeout unlocking Persistent Storage while processing the side-effects of udevadm trigger (wb:a30fc0ec5ed66e8b8b15e6f3d6c5914b, wb:da6206f8672a28526aa21df26b5888ab, wb:a2f6e2f3eaa1be2eed2d4d7c602becea).
The last thing tpsd logged in dmsetup rename luks-2739fadb-1834-4eb7-a179-6e1b606aafba TailsData_unlocked. But in the background, the system is still digesting the effects of udevadm trigger that we ran just before (because we don't use --settle). This is known to get some systems stuck, unfortunately.
I think wait_for_udisks_object using a blanket udevadm trigger is a very big hammer and perhaps this kind of problem could be avoided if we passed some relevant --type and --action (for example) parameters. Alternatively, on @anonym proposed to call udevadm trigger DEVPATH.
For examples about the kind of problems this may cause, and how we avoid them elsewhere in our codebase:
- No network when "udevadm settle" failed despite... (#20045 - closed)
- Breaks activating the Persistent Storage in the Welcome Screen (wb:3228e8db3b3d5fed0af52339d870c2b6)
- see 18b2d121
- It might have broken ALSA/PipeWire in a test suite run (#20344 (closed))
And regarding udevdam settle (still used in Activate): maybe udevadm wait DEV would be enough for our needs here, without having to assume anything about successful initialization of unrelated drivers?
Benefit and cost
Benefits: as of 2024 Q1, this is one of the main causes of bug reports sent by users. It prevents many users from using Persistent Storage. So the benefits of fixing this are great.
Cost: trying out 1 of the approaches proposed on this issue should be cheap. Then we can iterate after having released the tentative fix and seen what kind of problems are left.