which is from /usr/lib/udisks2/udisks2-inhibit. This is a race condition, when polkit gets killed at the wrong time while a request is pending it would behave that way. Curious that this only surfaces right now, /usr/lib/udisks2/udisks2-inhibit has been like that for a while already.
All of your traces got interrupted in poll() though, i. e. there was no pending request (no recv* yet), so this did not interrupt a pending call. However, this is still bad.
Thing to try on a machine which reproduces this: Please comment out all the code except the final "$@" from /usr/lib/udisks2/udisks2-inhibit (from initramfs break=casper-bottom) and verify that this crash then stops. Then, once you are in ubiquity, run "pkill -e --signal STOP gvfs-udisks" to stop gvfs-udisks2-volume-monitor (but that does not apply to all derivatives, such as KDE).
I'll think about how we can inhibit udisks without having to restart polkit.
Thanks Mathieu; all your traces indeed have
+++ killed by SIGHUP +++
which is from /usr/lib/ udisks2/ udisks2- inhibit. This is a race condition, when polkit gets killed at the wrong time while a request is pending it would behave that way. Curious that this only surfaces right now, /usr/lib/ udisks2/ udisks2- inhibit has been like that for a while already.
All of your traces got interrupted in poll() though, i. e. there was no pending request (no recv* yet), so this did not interrupt a pending call. However, this is still bad.
Thing to try on a machine which reproduces this: Please comment out all the code except the final "$@" from /usr/lib/ udisks2/ udisks2- inhibit (from initramfs break=casper- bottom) and verify that this crash then stops. Then, once you are in ubiquity, run "pkill -e --signal STOP gvfs-udisks" to stop gvfs-udisks2- volume- monitor (but that does not apply to all derivatives, such as KDE).
I'll think about how we can inhibit udisks without having to restart polkit.