| Summary: | KScreenlocker not unlockable when there are multiple sessions on NFS home | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreenlocker | Reporter: | Tim Eberhardt <tim.eberhardt> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | bshah, kde, mgraesslin, rdieter, slavikvin |
| Priority: | NOR | ||
| Version First Reported In: | 5.5.5 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Tim Eberhardt
2016-08-04 11:30:02 UTC
If you see the dialog it means that the helper process crashed a few times in that situation. Could you please try to get a backtrace for it? I assume that this will also happen when invoking the helper process manually. Thus you could run: gdb --args /usr/lib/<arch>/libexec/kscreenlocker_greet --testing once gdb is started, press r to run it, it should show the lock dialog. Then please continue with step 2 onwards. Ideally that should crash and you can get to the backtrace with "t a a bt". I don't know exactly where on opensuse the binary is installed. This differs from distro to distro, thus I replaced a part with <arch>. Unfortunately kscreenlocker_greet is working perfectly when I run it in gdb or in a pure shell with or without --testing option. Only if I wait for the set timeout or hit the shortcut to lock the screen I get the error described above. Additionally I have observed that the second session has not to be locked to crash kscreenlocker on the first session. It begins to happen as soon as there is a newer session then the one running. ah what a pity. I hate it if things are not reproducable in the test setup. What I'm wondering: are the sessions adjusted to have sockets and other runtime information not on the NFS share? I can imagine that it could create problems if the socket of process on system A gets overwritten by a socket created by a process on system B. I don't know what else could be adjusted but the socket, cache and tmp links under ~/.kde4 point to /run/..., /var/tmp/... and /tmp/... respectively. As an aside, one thing I learned from using nfs $HOME, that seems to help a lot, is to consider setting environment variables: XDG_CACHE_HOME KDEHOME XDG_CONFIG_HOME XDG_DATA_HOME to point to local disk-based storage. A downside of the latter 3 is that means your configuration is no longer stored in $HOME, so won't necessarily follow you to other machines though. I now tested with XDG_CACHE_HOME set to somewhere under /var/tmp which gets then populated with some stuff, but brings no difference to this problem. All settings should remain in the users home. The same thing happens when I update my Arch system (presumably also updating the screen locker) and then lock the screen without restarting the session. It's pretty reproducible in that scenario. All I get then is this message saying "The screen locker is broken and unlocking is not possible anymore…" I think this should be fixed. You can't expect all users to understand this message and follow the instructions every time they update their system. Some don't even have spare VTs anymore so they have to restart the PC and kill their running session. > I think this should be fixed.
Yes I agree it should be fixed. But for that we need to see the backtrace - without it we have no clue what's going on.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you! Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |