Community
Participate
Working Groups
After my machine went down, I am unable to convince Eclipse to load up my workspace again. It tells me that it is locked, when clearly it is not. There needs to be a way to address this.
A solution to this would look like the following: user selects (or comes up in if there's a default selection) a locked workspace dialog appears saying it's locked and asks if you'd like to unlock it. It should warn that if the workspace really is currently in use that it'll do all kinds of horrible things if the user clicks yes to delete the lock it does so. otherwise bring up the selection dialog.
Hi Kim, i'd like to pick this up for bugday if that's ok?
By all means, please! Anything with the bugday keyword is fair game. :)
Kim, was looking at this over the weekend and i'm a little confused. I have checked the "lock()" and "release()" methods of "Locker_JavaIo.java" and given their implementations cannot see how a user will end up with a locked workspace after an Eclipse crash? Also, I can't replicate this bug even when i pull the plug on machine at the wall. Did the "lock()" method originally just check for the presence of the ".lock" file (no deletion check?) and report an error on finding it (assuming Eclipse would have deleted it on normal exit)? This would explain the locked workspace behaviour after a crash. Or is there a special circumstance under which this situation can, currently, arise?
I would've thought the behaviour you described would cause the problem but it might be that the problem no longer exists. Pascal, should this be an issue any longer?
I belive we can solve it in Students' Eclipse Group of Interest
Bartosz, have you verified this is still a problem and if so how did you reproduce it?
confirmed. this is not a problem for 3.4M2
Prakash is now responsible for watching bugs in the [WorkbenchLauncher] component area.
*** Bug 346612 has been marked as a duplicate of this bug. ***
There is a good suggestion how to address this, along with a good comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=293910#c1
*** Bug 76625 has been marked as a duplicate of this bug. ***
*** Bug 78582 has been marked as a duplicate of this bug. ***
*** Bug 293910 has been marked as a duplicate of this bug. ***
Now that we have 4 duplicates of this, is there a case for increasing priority from its current P5 ? - I liked the suggestion and short discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=293910 Some ideas for improving the situation: 1. Instead of an empty .lock file, write hostname + PID + Eclipse application ID into the .lock file. That way, when the process crashes hard or the machine reboots (eg out of battery), the .lock file can be safely removed when on the same host and the PID doesn't exist any more. It's the typical way how this has been dealt with on Linux, and this should capture perhaps 80% of the issues without any new UI. 2. In case the hostname is different in the .lock file, improve the error message ("...seems to be locked by "${Eclipse_application_ID} on ${hostname}" This helps checking whether a valid instance is still on the workspace or not. 3. In case the hostname is identical AND the PID is still running, improve the message ("... seems to be locked by "${Eclipse_application_ID} PID ${PID}" Ideally allow killing PID ${PID} at this point. 4. In case the .lock file does not have the new (hostname, PID, appID) format, it might have been created by an older Eclipse. Offer a message like {..seems to be locked by an unknown Eclipse session} and allow to delete the .lock file [deletion will likely fail if process is still running]. Thoughts ?
CQ:WIND00444398
(In reply to Martin Oberhuber from comment #15) > > Thoughts ? That kind of behaviour certainly seems reasonable. The PID interaction seems like it would require native fragments. PW
I think that even shooting for a very simple solution could provide good improvement. Just printing "some meaningful data" about the instance that seems to lock the workspace is in the .lock file will already help. From that point of view, it seems that the ManagementFactory.getRuntimeMXBean().getName(); might be good enough for our purpose, but I didn't check whether that also exists on non-Oracle VM's and what it's output format would be. See also http://stackoverflow.com/questions/5200269/list-of-running-jvms-on-the-localhost Note that Java 8 gives access to the PID officially and natively: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244896 providing full access to the PID as well as killProcess(), so pretty simple code protected by try {...}catch(NoSuchMethodError) should provide tangible improvement without JNI. So, rather than writing a JNI fragment it might make sense shooting for a simple solution that only works on Java 8 and higher. The goal would be incremental improvement with a simple patch. With a planned GA in March 2014, this would be good timing for a Java 8 based solution.
Lars I wanted to bring this ER to your attention, it looks like a very interesting usability improvement, what do you think ? Again and again we have users whose machine goes down (eg bluescreen due to power button pressed) while Eclipse is running. Then the workspace is still locked, and it's not intuitive at all how to unlock. Another use-case is workspace on a shared drive and two different Eclipse (on different host each) try to access the workspace. Then the locking is valid, but the dialog doesn't help much since it won't tell which host still locks the workspace. My https://bugs.eclipse.org/bugs/show_bug.cgi?id=80734#c15 proposes a solution ... CQ:WIND00-WB4-63
Martin, is this really an issue? I do remember having a few crashes on Windows but never experienced the described locking issue. Same on Mac. Never had a lock problem after any crash there and on Windows. AFAIK the algorithm is relying on file system level locking on Windows already. Thus, after a crash/reboot, no process should have a lock on the ".lock" file and it should be able to start. I would check if there are virus scanner, that could cause a lock on the ".lock" file.
Martin, AFAIK the .lock gets removed automatically if Eclipse crashes on the Equinox level. Adding Tom for details.
(In reply to Lars Vogel from comment #21) > Martin, AFAIK the .lock gets removed automatically if Eclipse crashes on the > Equinox level. Adding Tom for details. By default the workspace lock is using process locks on a file using java.nio. I don't see how the presence of a .lock file is causing the workspace to appear locked. Only if the user is using osgi.locking=java.io would this pose an issue. Is that the case here?
Ah, turns out our user was using an older Eclipse, and the workspace was on an NFS-mounted home on Linux. I'll check if I can reproduce with Neon. Thanks ! Martin
(In reply to Martin Oberhuber from comment #23) > Ah, turns out our user was using an older Eclipse, and the workspace was on > an NFS-mounted home on Linux. I'll check if I can reproduce with Neon. > > Thanks ! > Martin I seem to recall way back Java had a hard time implementing nio locks across an NFS-mounted file system. As a result I think the workaround was to use osgi.locking=java.io It is possible they are using that setting as a workaround. I am unsure if things have improved here to allow them to remove that workaround for NFS-mounted directores.
(In reply to Thomas Watson from comment #24) > (In reply to Martin Oberhuber from comment #23) > > Ah, turns out our user was using an older Eclipse, and the workspace was on > > an NFS-mounted home on Linux. I'll check if I can reproduce with Neon. > > > > Thanks ! > > Martin > > I seem to recall way back Java had a hard time implementing nio locks across > an NFS-mounted file system. As a result I think the workaround was to use > osgi.locking=java.io > > It is possible they are using that setting as a workaround. I am unsure if > things have improved here to allow them to remove that workaround for > NFS-mounted directores. See bug 44735 and http://bugs.java.com/view_bug.do?bug_id=6628575. The Eclipse part was fixed long time ago, the Java part should be fixed in Java 7.
Created attachment 268052 [details] ws_locked_20170427.png screenshot For the records, I just ran into this again during my work. Eclipse is Mars.2 , the host is CentOS 6.8, the workspace is on NFS: [maoberhu@vdi8461 workspace]$ mount | grep eclipseindex ahst2100-nas01:/var317/ahs_eclipse_index on /eclipseindex type nfs (rw,addr=121.46.132.17) It looks like I had kept my Workbench running (like lots of users do here) when IT decided to reboot the VDI Host machine. I'm working on multiple hosts, so I don't track such reboots. As a result, the workspace/.metadata/.lock file was not removed. When logging in and trying to work again, I see attached (ws_locked_20170427.png) : Not helpful at all ! As a user, I need a better hint that helps me recover from the problem, in case my workspace is locked on NFS after a reboot of the host.
Created attachment 268421 [details] Screenshot of workspace locked on MacOSX with Oxygen M7 Ran into this again, this time on MacOSX 10.11.7 El Capitan running the fresh Oxygen M7 Eclipse SDK -- see attached screenshot. I don't remember why or how my Mac crashed, probably battery drained to exhaustion over night due to a rogue process. It looks like the Eclipse session that I had running when it crashed wasn't terminated cleanly, leaving the stale lockfile. The lockfile has a date from March 24 (6 weeks ago), i don't use this workspace often. Proposed fix: The dialog from the screenshot should have a button for "force unlock now" with a questionmark-hyperlink to learn more about possible causes and consequences.
As a very first step, what about simply changing the message text from: " The default workspace '/path/to/ws' is in use or cannot be created. Please choose a different one. [OK] " to " The default workspace '/path/to/ws' is in use or cannot be created. If you think that the workspace is locked incorrectly, you may consider deleting the file '<workspace>/.metadata/.lock' end try again. Otherwise, please choose a different workspace. [OK] "
Created attachment 268489 [details] Example dialog allowing to break a lock On second thought, I think that exposing internals of the .lock file to end users doesn't look very good. Perhaps it would be best, to simply allow the user break the lock from the dialog? I guess 99% of the time, users would know whether they can break the lock, or whether an older instance could actually still use the workspace. See attached for what I see in KeepassX, as an example. We can’t open the workspace read-only, but allowing to break the lock should be simple. Just replace the “OK” by a “Yes/No” dialog, tune the wording, and remove the .lock in the code if Yes is pressed. Any thoughts anyone?
(In reply to Martin Oberhuber from comment #29) > Perhaps it would be best, to simply allow the user break the lock from the > dialog? I don't think so. > I guess 99% of the time, users would know whether they can break the lock, > or > whether an older instance could actually still use the workspace. In 99% of the time user will shoot himself in the foot, and the rest 1% will reboot Windows als ultimate solution for everything. > Any thoughts anyone? I wonder how you can get into the state at all, where you can't obtain a lock to a file which is not locked anymore by a running Eclipse instance. I think if this is a NFS issue with stale file handles, you should investigate how we can better handle this, means why the lock remains and if this is unavoidable, how we can detetct such cases. One possibility would be to write user, host and pid into the file so the check if the file is locked could check if there is a process of the same user on that host still alive. In general, I would not provide the average user the possibility to break the lock. Most of them never read dialogs, and if they read, can't understand our (developers) language anyway, so they will break the lock for still running workspaces all the time and run in even more troubles. This is a box of Pandora, don't open this.
(In reply to Andrey Loskutov from comment #30) Hi Andrey, I very much appreciate your comments, and I really feel with you (in fact I had been arguing the same way in the past). But I have some counter arguments: * This bug has been open since 2004, and in Oxygen - 2017 it's still hurting me. Perhaps we've been discussing too complex approaches all the time. IMO, a simple solution that covers the 90% case is better than waiting another 13 years for a 100% solution. > In 99% of the time user will shoot himself in the foot, and the rest 1% will > reboot Windows als ultimate solution for everything. * I strongly disagree. In this workflow, I'm launching Eclipse and try to open my workspace. I see the dialog, now I think "what the heck". I'll not break the lock if I have any doubts regarding the workspace still locked. But 90% of the time, removing the .lock will be just the right thing. I fail to see how I would shoot myself in the foot here ? > I wonder how you can get into the state at all, where you can't obtain a > lock to a file which is not locked anymore by a running Eclipse instance. I * On MacOSX, my computer crashed and on restart the .lock was blocking my workspace. No magic around here, local SSD formatted with default HFS+. I am 100% convinced that this will happen to other innocent users as well. On Linux, it's proably harder to reproduce but having the workspace on NFS while you plug the cable and reboot is most likely sufficient. > think if this is a NFS issue with stale file handles, you should investigate > how we can better handle this, means why the lock remains and if this is > unavoidable, how we can detetct such cases. One possibility would be to > write user, host and pid into the file so the check if the file is locked > could check if there is a process of the same user on that host still alive. * Very true, and I have proposed exactly this before, but there are complexities: - Deal with older versions of Eclipse which don't write user/host/pid into .lock yet - On NFS, if the lock is from a different machine, you still won't be much wiser if you can break it or not Bottom line yes, putting the extra user/host/pid into the file will clearly help but to me this is just the topping of the cake making the feature more usable. It's not a must-have. The must-have is _enabling_ the user to break the lock. As Jeff McAffer always said: Make simple things simple, make hard things possible. It's really simple allowing the user to break the lock intuitively, and I fail to see the risk/drawback of enabling this if we craft a reasonable message explaining the situation.
(In reply to Martin Oberhuber from comment #31) > > In 99% of the time user will shoot himself in the foot, and the rest 1% will > > reboot Windows als ultimate solution for everything. > > * I strongly disagree. In this workflow, I'm launching Eclipse and try to > open > my workspace. I see the dialog, now I think "what the heck". I'll not > break the > lock if I have any doubts regarding the workspace still locked. But 90% of > the time, removing the .lock will be just the right thing. > > I fail to see how I would shoot myself in the foot here ? User double clicks on the Eclipse icon and launches Eclipse multiple times on same workspace. He will not realize this and click on handy "remove the lock" button. From here on, he will destroy as much internal workspace data (.metadata) as possible - preferences, indexes, resource database, whatever else programmed with the assumption that there is a workspace lock and they have exclusive access to .metadata files. > > I wonder how you can get into the state at all, where you can't obtain a > > lock to a file which is not locked anymore by a running Eclipse instance. I > > * On MacOSX, my computer crashed and on restart the .lock was blocking my > workspace. > No magic around here, local SSD formatted with default HFS+. I am 100% > convinced > that this will happen to other innocent users as well. On Linux, it's > proably > harder to reproduce but having the workspace on NFS while you plug the > cable > and reboot is most likely sufficient. If we would fail to create a lock, why shouldn't we fail to delete file in this case? I believe this is "exclusive or" case. Either we can lock and have no problem, or we can't lock but also can't delete the faulty file, locked by NFS. > > think if this is a NFS issue with stale file handles, you should investigate > > how we can better handle this, means why the lock remains and if this is > > unavoidable, how we can detetct such cases. One possibility would be to > > write user, host and pid into the file so the check if the file is locked > > could check if there is a process of the same user on that host still alive. > > * Very true, and I have proposed exactly this before, but there are > complexities: > - Deal with older versions of Eclipse which don't write user/host/pid into > .lock yet I don't think we will have multiple *different* versions of Eclipse trying to access locked files after NFS lock & crash. The probability of this is even lower as the crash holding NFS lock issue alone. I think we shouldn't care about this. > - On NFS, if the lock is from a different machine, you still won't be much > wiser > if you can break it or not At least the user will know that someone else is accessing the same workspace from a different host right now. We have our software tester sharing same account, even if they all sit in a single room, you can't believe how often they were trying to "fix" something in same workspace in parallel, without asking others if there is someone using it. > Bottom line yes, putting the extra user/host/pid into the file will clearly > help but > to me this is just the topping of the cake making the feature more usable. > It's not > a must-have. The must-have is _enabling_ the user to break the lock. *If* we are going to implement something, I would expect that this UI would at least contain some info *who/where* could access the "locked" workspace right now. > As Jeff McAffer always said: Make simple things simple, make hard things > possible. Removing the workspace lock is not simple, it is dangerous. > It's really simple allowing the user to break the lock intuitively, and I > fail to see the risk/drawback of enabling this if we craft a reasonable message > explaining the situation. As said, most users simply will read the message and do the opposite of what you would expect, means they will most likely destroy they workspaces. Because this is much more severe than just not being able to conveniently remove the lock, I think the impact is way higher. But again, I question if we can actually "fix" the problem by removing the lock file, because just the presence of the file does not harm. It is the lock on that file which prevents you to start the workspace, and if the lock is really there, we will be not able to remove it *automatically*. So the only way I see to "fix" the problem is to explain all this to the user, which also means we need explain him not only workspace internal things but also NFS, file locking etc. I doubt this will be useful for an average user at all.
This seems to be a Linux only issue. On my Windows 7 machine, when I kill java.exe or the shell that started Eclipse, I still have the .lock file but starting the workspace just works fine.
(In reply to Dani Megert from comment #33) > This seems to be a Linux only issue. Or at least not a Windows issue.
(In reply to Andrey Loskutov from comment #30) > (In reply to Martin Oberhuber from comment #29) > > Perhaps it would be best, to simply allow the user break the lock from the > > dialog? > > I don't think so. I agree! Such a button would be dangerous and as commented before unnecessary on Windows, because there it just works. So, we should take a closer look why it does not work on Mac and also test on Linux.
Ok, so let's take a step back here. 1. The problem is real. I've experienced it many times - most often on Linux/NFS, 2 times on MacOSX and also 2-3 times on Windows in the past. For example, have your workspace on a USB disk, hibernate Windows while Eclipse is running, unplug the USB disk, unhibernate -- I'm quite sure the workspace will be locked when you try to open it the next time. Same for workspace on SMB mount when the network cable is plugged. 2. On the other hand, our users are developers. If they act like myself, when they see the dialog they'll google "Eclipse workspace cannot be locked" which goes here: https://stackoverflow.com/questions/8489322/eclipse-says-workspace-in-use-or-cannot-be-created-chose-a-different-one-ho and voila, there is the solution. So is the issue a blocker? - No, friend Google w/ Stackoverflow come to the rescue. Is it worth taking any risk? - No, reading stackoverlflow and manually intervening is likely safer. But still I think it's a significant usability issue. Especially for rebranded IDEs on top of Eclipse. Some of our customers don't even know they run Eclipse under the hood. They won't go to StackOverflow when they run into this. My scenarios may seem esoteric at first, but I've run into them often enough to know they are real. I've made many proposals over the years how this could be addressed, and yet it has been deferred again and again. Perhaps we should just go back to the improved message text, that explains the .lock file. Yes it does expose internals. But if I experience this situation, I prefer learning about internals than being blocked. I know about 2 customers of ours who wiped their workspaces because they didn't know there was a simple solution. I'm sure we can do better than this at Eclipse. Cheers, Martin
(In reply to Martin Oberhuber from comment #36) > 1. The problem is real. I've experienced it many times - most often on > Linux/NFS, > 2 times on MacOSX and also 2-3 times on Windows in the past. For example, > have your workspace on a USB disk, hibernate Windows while Eclipse is > running, > unplug the USB disk, unhibernate -- I'm quite sure the workspace will be > locked > when you try to open it the next time. Same for workspace on SMB mount > when > the network cable is plugged. Is this even a supported use case, i.e. running with workspace on USB or network drive? This always caused issues in the past (performance issues aside). FWIW, I never run into this issue on Windows and macOS.
(In reply to Martin Oberhuber from comment #36) > Perhaps we should just go back to the improved message text, that explains > the .lock file. Yes it does expose internals. But if I experience this > situation, I prefer learning about internals than being blocked. I know > about 2 customers of ours who wiped their workspaces because they didn't > know there was a simple solution. I'm sure we can do better than this at > Eclipse. Yep. I think we should do two things: 1) Write hostname/user/appname into the lock file 2) If we can't lock and have that info above, enhance the message with something like: "Workspace is locked by %app_name% started by user %username% from host %hostname% at %file_access_time%. To unlock this workspace, please make sure %app_name% is terminated. In case this does not help, and you are sure that the workspace is not used anymore by other application, please try to remove the file %workspace_path%/.metadata/.lock and start again." Patch is welcome: https://wiki.eclipse.org/Platform_UI/How_to_Contribute
(In reply to Andrey Loskutov from comment #38) > Yep. I think we should do two things: > 1) Write hostname/user/appname into the lock file > 2) If we can't lock and have that info above, enhance the message with > something like: "Workspace is locked by %app_name% started by user > %username% from host %hostname% at %file_access_time%. To unlock this > workspace, please make sure %app_name% is terminated. In case this does not > help, and you are sure that the workspace is not used anymore by other > application, please try to remove the file %workspace_path%/.metadata/.lock > and start again." > > Patch is welcome: https://wiki.eclipse.org/Platform_UI/How_to_Contribute I'm not sure it needs to be that exhaustive. Keep it short, so that the user will actually read the message. And as mentioned before, I have no issue mentioning the .lock file. If we decide to use another mechanism in the future, we just have to make sure we update the message accordingly. Also, said before: just improving the message a little bit would be acceptable for me for 4.7, but the change should come for RC2.
New Gerrit change created: https://git.eclipse.org/r/145666
From the gerrit: Old Message: Could not launch the product because the associated workspace at ''{0}'' is currently in use by another Eclipse application. Latest Proposal: Could not launch the product because the workspace at ''{0}'' is currently in use by another Eclipse application.\nClose this application to unlock the workspace. If you are sure that it is not used you may delete ''{1}''.\n\nAn erroneously force-unlock will damage the workspace irreversible. ''{1}'' = ''{0}''/.metadata/.lock What do you think? Are there any spelling mistakes etc.?
