https://bugs.kde.org/show_bug.cgi?id=508253
--- Comment #7 from Sebastian Sauer <[email protected]> --- Hello René, > I don't know whether I interpret the solution by > Sebastian Sauer> But to me it looks like it just > continues when the date on the lock file is in > the future. Correct. It prints a qInfo, which we also see in the logs you provided, and lets us know that something is wrong with the time when the stalee lockfile was created. It's in the future but shouldn't be. Also since that qInfo is in your logs we know that Qt proper detected that the lockfile is staled. After printing the qInfo Qt then tries to delete that staled lock file. That seems to fail since otherwise there would not be a problem. > If that is not what you are doing, then what about > showing a dialogue with information and the > options to "retry login" or "cancel login" ? Usually Qt should completely proper handle the case. That means even when a staled lock file was found the code I quoted shows us that Qt would usually detect that and fix the problem without anybody noticing that there was a problem. > In my opinion, the best user experience is to > show the user something, and not just die in > a "black" screen - so I hope that is avoided. The best, and expected, experience would be if Qt's QLockFile does handle all that automatically. It should and it has code to do that. Also when searching in our bugtracker and in the Qt bugtracker then there are VERY seldom cases where this not works. We of course agree 100% that it should always work and every case where it doesn't is a fatal one just like proven with this bug report. Lucky you are skilled, figured.the problem out and got it solved (and even reported it to us, lot of thanks!) but not everybody is in that position or has the motivation to go down the rabbit hole. Now I did future research since Nat rightfully suggested that: > If someone feels technically adventurous to > put together a Qt bug report about this at > https://bugreports.qt.io — ideally with a > small reproducer — that would be super helpful. We may not be able to fix it in our code (since currently it looks to be an issue in Qt's QLockFile itself) but of course we should also not just ignore it. For that the issue is IMHO to evil. That's why your bug report even made it into our high priority list. So let's look what we can do; The upstream issue that comes closest to the issue reported here is https://bugreports.qt.io/browse/QTBUG-93069 Thiago wrote there: > Not out bug. The problem is the fact that your device > had a date in the future when the lock file was > created. Fix ii. Devices must have correct times > soon after boot. > > Your logs say that Qt printed this warning: > > [...] > > Because it detected a date in the future, > d->isApparentlyStale will always return > false. So it never removes the lock file. > > (Strictly speaking, "never" and "deadlock" > are incorrect. The code is running just fine > and will exit in about 3 months) Now I don't got the "d->isApparentlyStale will always return false" part. It would not print the qInfo when d->isApparentlyStale would have returned false... Now Thiago is amazing so he is likely right and I am right now just to dump to get it. If he is right then the solution would be an upstream patch like: ``` - if (d->isApparentlyStale() && d->removeStaleLock()) + if (d->removeStaleLock()) continue; ``` At the bare minimum there should be some qWarbungs/qInfos in that try-to-remove-a-stale-lockfile fallback code IMHO. So maybe we can 1) create a Qt Burgreport with all the details and/or 2) create a patch for Qt to add some more qInfo/qWarning code. Of course if I would be able to reproduce the issue I could do much more like trying to come up with a proper fix for upstream :-/ I will try to use next days to think a bit more what else we can do. -- You are receiving this mail because: You are watching all bug changes.
