thiago added a comment.
In D14302#297515 <https://phabricator.kde.org/D14302#297515>, @dfaure wrote: > The idea of the old code was: if I can't get the lock, then someone else is already in the process of starting kdeinit, so I'll just wait for that to happen, by locking again, i.e. blocking on purpose, and then checking that the DBus name is up, i.e. the other process did manage to do it successfully. It's Kind of silly to tryLock() then lock(). Why not just lock()? Was it the optimisation to avoid the D-Bus call? If so, a comment would be warranted. > I said from the start that it wasn't tryLock() that was blocking but lock(), good to see that this is now confirmed, however we're back to square one: why is lock never returning? Surely the other process which is executing this method is releasing the lock after the QProcess::execute, right? Yeah, I trusted the patch too. The frame for lock() is missing because it's a tail-call jump. Anyway, one theory for why the lock file is still present: it's stale from a previous boot, but the PID is taken by some process in the current boot. This is fixed in Qt 5.11 by saving the boot ID (commit 772863355a0cf57a49e93608790dfd17c8fd82da). So question to @jtamate , what Qt version is this? Can you paste here the contents of the lock file itself, as well as what process (if any) the PID in that file points to. REPOSITORY R271 KDBusAddons REVISION DETAIL https://phabricator.kde.org/D14302 To: jtamate, dfaure, #frameworks, thiago Cc: lvsouza, kde-frameworks-devel, michaelh, ngraham, bruns
