I had this same problem where mountall consumed a lot of CPU cycles (and appeared to be busy-looping) in case fsck was performed. The program was not busy-looping, and did eventually exit by itself.
This behaviour was caused by an assertion at libply module, file ply-list.c, function ply_list_unlink_node(). The last line of the function asserts that the node was unliked properly by scanning through the list (lineat time operation).
When for (some reason) connection from mountall to plymouth was broken, the event loop noticed this, and application started to cancel pending requests (I had somehing like 300000 of those). The assertion, if present, basically leads to time quadratic behaviour for this cancellation operation.
This should not happen on non-debug (-DNDEBUG) builts.
More proper fix would be to figure out why the socket towards plymouth is closed, and keep that open as long as mountall/fsck is running.
Hello.
I had this same problem where mountall consumed a lot of CPU cycles (and appeared to be busy-looping) in case fsck was performed. The program was not busy-looping, and did eventually exit by itself.
This behaviour was caused by an assertion at libply module, file ply-list.c, function ply_list_ unlink_ node(). The last line of the function asserts that the node was unliked properly by scanning through the list (lineat time operation).
When for (some reason) connection from mountall to plymouth was broken, the event loop noticed this, and application started to cancel pending requests (I had somehing like 300000 of those). The assertion, if present, basically leads to time quadratic behaviour for this cancellation operation.
This should not happen on non-debug (-DNDEBUG) builts.
More proper fix would be to figure out why the socket towards plymouth is closed, and keep that open as long as mountall/fsck is running.
Br.
--
tmo