https://bugs.kde.org/show_bug.cgi?id=508253
--- Comment #12 from Sebastian Sauer <[email protected]> --- Thanks a lot for trying and all the additional informations provided! This one: > Some times it started immediately, other times I > could see on the server that the `.lock` file was > deleted after around 30 seconds, and then KDE > Plasma started. The 30 seconds delay is caused by: https://github.com/qt/qtbase/blob/dev/src/corelib/io/qlockfile_p.h#L50 ``` std::chrono::milliseconds staleLockTime = std::chrono::seconds{30}; ``` https://github.com/qt/qtbase/blob/dev/src/corelib/io/qlockfile.cpp#L458 ``` bool QLockFilePrivate::isApparentlyStale() const { [...] const QDateTime lastMod = QFileInfo(fileName).lastModified(QTimeZone::UTC); using namespace std::chrono; const milliseconds age{lastMod.msecsTo(QDateTime::currentDateTimeUtc())}; return staleLockTime > 0ms && abs(age) > staleLockTime; } ``` So in the NFS case it takes 30 seconds to realize that the lock file is stale. Once that was the case the lock file is proper removed. That's the expected behavior. Still not explains why, in the problem behavior case this Ticket is about, we can end in a situation where the stale state was proper detected but deleting the stale lock file fails then. And yes, it must be a very hard to reproduce condition since otherwise we would have seen more bugreports either in our bugtracker or in the Qt bugtracker about that issue. It could be well an issue even below the stack like with NFS or, as your quoted ChatGPT comment suggested, even the Kernel. Hard to say without more debugging what is unfortunately not so easy because it's hard to reproduce the issue. So if you, or if someone else who runs into this and reads this bugticket now, are ever able to reproduce this again a "strace plasmashell" would be very useful so we at least know what the syscalls do and return. Otherwise I fear there is currently not much we can do here. The maximum would be a patch for Qt to print more debug/qInfo's in the error case. But then it may hard to convince anybody during review that such a patch would be worth it :-/ At least we have now this jura ticket with lots of informations collected. So whenever somebody else runs into this a bug-search will show this Ticket and provide plenty additional informations to the reader. Lot of thanks again Rene. Great team work! -- You are receiving this mail because: You are watching all bug changes.
