Comment 1 Martin Oberhuber 2015-06-03 09:53:58 EDT

Workaround:

chmod -R 777 /home/vmuser/.eclipse/org.eclipse.platform_4.4.1*

Comment 2 Ed Merks 2015-06-03 10:17:46 EDT

Martin,

Oomph is designed to make it easy for users to produce their own installations, for for system admins to create shared installations.  I'm not sure such shared installations can be made to work, and certainly not without more effort than likely remains in the release cycle.

So I'd be more concerned whether an unpackaged normal package (also containing the Oomph runtime) does cause the same type of problem.  I suspect not, because of all this cascading config folder stuff that seems to be supported for this purpose but that we've never tested nor fully understood.  Could you test that scenario and report back?  We're just not Linux admin experts...

Comment 3 Martin Oberhuber 2015-06-03 10:44:18 EDT

(In reply to Ed Merks from comment #2)
Hi Ed,

I understand your point, but from a consumer point of view our users won't know whether eclipse-installer is meant for shared install purpose or not.

I'm afraid I don't have time today to test the package scenario and then it's public holidays until next week - but it's really super easy to test. Instead of creating user1 and user2, you could do root and normaluser. Then on ubuntu it boils down to

sudo bash
tar xfz yourpackage.tgz
eclipse/eclipse
# Help>About, then exit; I also had AERI report something
exit
# Now you're normal user again
eclipse/eclipse
# Help> About

Comment 4 Martin Oberhuber 2015-06-04 04:24:49 EDT

Here is a related issue, same install, different stack trace; in this case the workaround doesn't work since it tries to access a read-only item from inside the install:

java.lang.IllegalStateException: Registry Directory not available: /mnt/disk3/WindRiver/eclipse/e45rc2a_64/committers-mars/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry.
	at org.eclipse.oomph.p2.internal.core.LazyProfileRegistry.getProfileMap(LazyProfileRegistry.java:159)
	at org.eclipse.oomph.p2.internal.core.LazyProfileRegistry.getProfileMap(LazyProfileRegistry.java:150)
	at org.eclipse.oomph.p2.internal.core.LazyProfileRegistry.containsProfile(LazyProfileRegistry.java:131)
	at org.eclipse.equinox.internal.p2.engine.ProfilePreferences.containsProfile(ProfilePreferences.java:110)
	at org.eclipse.equinox.internal.p2.engine.ProfilePreferences.load(ProfilePreferences.java:253)
	at org.eclipse.core.internal.preferences.EclipsePreferences.create(EclipsePreferences.java:409)
	at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:670)
	at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:812)
	at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:676)
	at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:812)
	at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:676)
	at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:812)
	at org.eclipse.core.internal.preferences.EclipsePreferences.internalNode(EclipsePreferences.java:676)
	at org.eclipse.core.internal.preferences.EclipsePreferences.node(EclipsePreferences.java:812)
	at org.eclipse.core.internal.preferences.RootPreferences.getNode(RootPreferences.java:111)
	at org.eclipse.core.internal.preferences.RootPreferences.node(RootPreferences.java:90)
	at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.getSharedPreferences(AbstractRepositoryManager.java:518)
	at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.restoreRepositories(AbstractRepositoryManager.java:1016)
	at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.getKnownRepositories(AbstractRepositoryManager.java:480)
	at org.eclipse.oomph.p2.core.P2Util.getKnownRepositories(P2Util.java:98)
	at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.isNeeded(P2TaskImpl.java:594)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.initNeededSetupTasks(SetupTaskPerformer.java:1496)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin.performStartup(SetupUIPlugin.java:427)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin.access$3(SetupUIPlugin.java:310)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin$1$1.run(SetupUIPlugin.java:210)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Comment 5 Martin Oberhuber 2015-06-05 05:35:55 EDT

(In reply to Ed Merks from comment #2)
> So I'd be more concerned whether an unpackaged normal package (also
> containing the Oomph runtime) does cause the same type of problem. 

It does show the problem, I tested with eclipse-committer RC3. Here is the 
AERI Report with backtrace etc:

https://dev.eclipse.org/recommenders/community/confess/#/incidents/0GRBDjq6ge0fJs4WnYp3qn8jmbDV5xc8JCCe0xkYiyQWdP6wCQ0WYqmRFpXPWoqH

Steps to reproduce, this is exactly what I did:
-----------------------------------------------
1. su - vmuser
2. cd /mnt/disk3/eclipse/e45rc3/committers
3. wget https://hudson.eclipse.org/packaging/job/mars.epp-tycho-build/238/artifact/org.eclipse.epp.packages/archive/20150604-1155_eclipse-committers-mars-RC3-linux.gtk.x86_64.tar.gz
4. tar xfz 20150604-1155_eclipse-committers-mars-RC3-linux.gtk.x86_64.tar.gz
5. eclipse/eclipse -data workspace
   # I did Help > Install software to install TM Terminal;
   # And, with Oomph Prefs Recorder active, I enabled Print Margin
   # Then, quit Eclipse
6. exit
   # Now I'm normal user again
7. /mnt/disk3/eclipse/e45rc3/committers/eclipse/eclipse -data myws
   # Imported an existing workspace
   # During the autobuild, AERI started and prepared the error report above.

Comment 6 Martin Oberhuber 2015-06-05 06:02:42 EDT

Update:

When only extracting the committers package as vmuser (but never launching it), the "Help > About > Installation Details" workflow works OK as normal user. So it looks like there is a workaround for some of the issues.

But still, trying to install an add-on plugin as normal user runs into this issue and the "Next" button is disabled and this issue is reported:

https://dev.eclipse.org/recommenders/community/confess/#/incidents/6yIevPVqEr0w5EJ9o3ClA3gFymtWhQGkNAoS5u4wBHpDsbVenWtJSYEJWFDqbJy5

This is a blocking issue for a very important workflow (read-only master Eclipse exists, but end-user installs a local add-on).

Unless this issue can be fixed (which I suppose is unlikely that late in the game), I think that for Mars, it needs to be documented on a prominent place that the Eclipse Packages which contain Oomph are not suitable for read-only multi-user installs. 

I'm thus marking this issue as blocking bug 459836 to raise visibility. Ideally, you guys could find a workaround for removing Oomph Setup from a package, such that an admin who does a read-only multi-user install can learn what to do...

Comment 7 Ed Merks 2015-06-05 11:40:02 EDT

Martin,

Is it normal to expect to be able to install new things into a shared Eclipse installation for which you have no write permission?   I guess it must be, because otherwise you'd not be trying to do that...

We'll investigate how P2 behaves by default so we can replicate that behavior.  Somehow such additional installation information (downloaded bundles and profile) must be maintained in the user's home space because clearly one can't allow users to actually update a shared installation. 

Thanks for testing this and reporting it.  I'm sure well find a fix quickly.

Comment 8 Ed Merks 2015-06-05 12:07:19 EDT

One observation I have already is that this returns the configuration folder in the read only installation

org.eclipse.core.runtime.Platform.getConfigurationLocation()

I.e., converted to a URI like this in my case:

  file:/D:/sandbox/tmp/committers-latest-read-only/eclipse/configuration

We certainly won't be able to create an Installation.setup at such a location.  

In terms of the profile, it obviously can't be locked, but then it's not clear why the self profile would need to be locked, and we'll have to figure how how the SimpleProfileRegistry avoid these problems...

Comment 9 Ed Merks 2015-06-05 13:00:21 EDT

Another observation is that the simple profile has the same problem:

java.lang.IllegalStateException: Profile not locked due to exception: D:\sandbox\tmp\committers-latest-read-only-simple\eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\D__sandbox_tmp_committers-latest-read-only-simple_eclipse.profile\.lock (Access is denied)
	at org.eclipse.equinox.internal.p2.engine.ProfileLock.lock(ProfileLock.java:108)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.restore(SimpleProfileRegistry.java:529)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfileMap(SimpleProfileRegistry.java:365)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.internalGetProfile(SimpleProfileRegistry.java:249)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfile(SimpleProfileRegistry.java:179)
	at org.eclipse.oomph.p2.internal.core.AgentImpl.getCurrentProfile(AgentImpl.java:325)
	at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.isNeeded(P2TaskImpl.java:583)
	at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.initNeededSetupTasks(SetupTaskPerformer.java:1496)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin.performStartup(SetupUIPlugin.java:427)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin.access$3(SetupUIPlugin.java:310)
	at org.eclipse.oomph.setup.ui.SetupUIPlugin$1$1.run(SetupUIPlugin.java:210)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
	
It just happens sooner.

E.g., here is one showing the about installation, with no Oomph on the stack.  

java.lang.IllegalStateException: Profile not locked due to exception: D:\sandbox\tmp\committers-latest-read-only-simple\eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\D__sandbox_tmp_committers-latest-read-only-simple_eclipse.profile\.lock (Access is denied)
	at org.eclipse.equinox.internal.p2.engine.ProfileLock.lock(ProfileLock.java:108)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.restore(SimpleProfileRegistry.java:529)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfileMap(SimpleProfileRegistry.java:365)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.internalGetProfile(SimpleProfileRegistry.java:249)
	at org.eclipse.equinox.internal.p2.engine.SimpleProfileRegistry.getProfile(SimpleProfileRegistry.java:179)
	at org.eclipse.equinox.internal.p2.ui.model.ProfileElement.getQueryable(ProfileElement.java:56)
	at org.eclipse.equinox.internal.p2.ui.QueryProvider.getQueryDescriptor(QueryProvider.java:88)
	at org.eclipse.equinox.internal.p2.ui.model.QueriedElement.fetchChildren(QueriedElement.java:101)
	at org.eclipse.equinox.internal.p2.ui.model.QueriedElement.getChildren(QueriedElement.java:69)
	at org.eclipse.equinox.internal.p2.ui.viewers.ProvElementContentProvider.getChildren(ProvElementContentProvider.java:134)
	at org.eclipse.equinox.internal.p2.ui.viewers.DeferredQueryContentProvider.getChildren(DeferredQueryContentProvider.java:119)
	at org.eclipse.equinox.internal.p2.ui.viewers.DeferredQueryContentProvider.getElements(DeferredQueryContentProvider.java:85)
	at org.eclipse.jface.viewers.StructuredViewer.getRawChildren(StructuredViewer.java:1000)
	at org.eclipse.jface.viewers.ColumnViewer.getRawChildren(ColumnViewer.java:700)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren(AbstractTreeViewer.java:1349)
	at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeViewer.java:353)
	at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildren(StructuredViewer.java:906)
	at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:617)
	at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:815)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:791)
	at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:611)
	at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:762)
	at org.eclipse.jface.viewers.AbstractTreeViewer.internalInitializeTree(AbstractTreeViewer.java:1541)
	at org.eclipse.jface.viewers.TreeViewer.internalInitializeTree(TreeViewer.java:790)
	at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1525)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1462)
	at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:366)
	at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1423)
	at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1517)
	at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:292)
	at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1701)
	at org.eclipse.equinox.internal.p2.ui.dialogs.InstalledIUGroup.createViewer(InstalledIUGroup.java:72)
	at org.eclipse.equinox.internal.p2.ui.dialogs.StructuredIUGroup.createGroupComposite(StructuredIUGroup.java:79)
	at org.eclipse.equinox.internal.p2.ui.dialogs.InstalledIUGroup.<init>(InstalledIUGroup.java:51)
	at org.eclipse.equinox.p2.ui.InstalledSoftwarePage.createControl(InstalledSoftwarePage.java:107)
	at org.eclipse.ui.internal.about.InstallationDialog.tabSelected(InstallationDialog.java:280)
	at org.eclipse.ui.internal.about.InstallationDialog.createContents(InstallationDialog.java:250)
	at org.eclipse.jface.window.Window.create(Window.java:430)
	at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:1096)
	at org.eclipse.jface.window.Window.open(Window.java:792)
	at org.eclipse.ui.internal.dialogs.AboutDialog$1.run(AboutDialog.java:126)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
	at org.eclipse.ui.internal.dialogs.AboutDialog.buttonPressed(AboutDialog.java:120)
	at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:619)
	at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4180)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3769)
	at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
	at org.eclipse.jface.window.Window.open(Window.java:803)
	at org.eclipse.ui.internal.about.AboutHandler.execute(AboutHandler.java:33)
	at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295)
	at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
	at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
	at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
	at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
	at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
	at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
	at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
	at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:160)
	at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:595)
	at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:511)
	at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:420)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4362)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1113)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4180)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3769)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
	
This all of course makes me wonder how this ever works even without Oomph.  It's clear the profile can't be locked when the folder is read only and it seems clear that p2 itself when restoring the self profile will try to do this too....

Comment 10 Martin Oberhuber 2015-06-06 01:21:59 EDT

(In reply to Ed Merks from comment #7)
> Is it normal to expect to be able to install new things into a shared
> Eclipse installation for which you have no write permission?

Hi Ed, shared read-only multi-user installs are working since Luna, this is related to all the work that Pascal Rapicault has put into the p2 
"Remediation" feature. Essentially, this is my understanding of how it works:

1. When the ECLIPSE_HOME/configuration folder is read-only, Eclipse
   creates a layered user configuration area with default location at
     $HOME/.eclipse/PRODUCT_ID_HASHCODE
   where the hashcode is computed from the installation path. So you get one
   user-owned writable configuration area per read-only install that you use.

2. The user configuration area "sees" all installed stuff from the parent and
   you can also add stuff (install) but you can only uninstall stuff that you
   installed yourself.

3. If the read-only parent gets updated, the Remediation kicks in on the next
   product launch. Essentially this is a dialog that prompts you to reinstall
   all the software from your writable user config area such that dependencies
   to the now changed read-only parent are resolved.

The work was tracked through a number of bugzilla items to cover various stages, and Pascal had sent a number of E-Mails to the cross-project mailing
list to explain the work. Personally, I had written up 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305642 which was marked as 
resolved in Luna.

We are using read-only config areas in our commercial product installs, that's why I care about the feature (and usually make all my installs read-only to ensure it gets some test exposure). Related to your observations, I'm surprised that

   org.eclipse.core.runtime.Platform.getConfigurationLocation()

returns the read-only parent; I would have expected that code returning the
writable user configuration area, but I don't know that code well enough
to judge. I'm adding Pascal Rapicault on CC, perhaps he can help with
more details if needed.

Comment 11 Ed Merks 2015-06-06 03:04:58 EDT

Thanks so much for this information!! I'm getting somewhere now.  It's quite tricky to make a folder really be read-only on Windows, chmod -R -w doesn't do the trick.  Also, the basic operation of making a folder read-only (as it says, applies only to files), so the folder itself remains writable (also in terms of what's returned by File.canWrite()).  One must use the security tab to deny write access for the current owner (myself).   Doing that properly, I'm getting the behavior you describe above, and I've verified that if I eliminate the lazy registry from the picture (remove the registration for the service), that all works well with no error log exceptions.  That's now a good basis to figure out what the lazy registry is doing wrong.

Comment 12 Ed Merks 2015-06-06 07:09:43 EDT

The fix is committed to master:

http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=80086f295d836d8780708ff9aad2dd964098cb94

The basic idea is to ensure we don't create a LazyProfileRegistry for a read-only profile location.  Then all of the platform's and p2's normal mechanisms kick in and all works happy.

Note that I've only tested this with a non-pooled installation (which produces a result the same as unzipping a pre-built package).  I'm not sure what happens if a pool is used and then the pool is read-only.  This might well work as well.  Further testing is needed...

Comment 13 Ed Merks 2015-06-06 09:08:01 EDT

*** Bug 468728 has been marked as a duplicate of this bug. ***

Comment 14 Martin Oberhuber 2015-06-10 02:43:38 EDT

Hi Ed,

On Linux as admin, I've used Oomph Integration #1425 from Hudson (dated 20150610-1225am) in order to install eclipse-committers-mars (I suspect I get RC3 as of today).

When launching this install as normal user, I'm getting this:
https://dev.eclipse.org/recommenders/community/confess/#/incidents/Grwyk1u0qYZ1b9r8ojYuyBjXOak7sVCYy48haWuXsUPqVw7YO6pQIDf6LyGaDhl0

I suspect that this is due to the (old) RC3 bits being installed so perhaps I don't see your fix yet ? - The AERI incident should have all the details for you to know, including plugin versions from the config. Let me know if I can help with any additional information. I'll reopen the defect for now until it's investigated.

Comment 15 Ed Merks 2015-06-10 03:15:09 EDT

It looks like the new bits are there and in fact this message looks like Equinox runtime's mechanism for cascading to a local writable configuration area has also kicked in.

org.eclipse.oomph.util.ReflectUtil$ReflectionException: java.lang.IllegalStateException: Profile not locked due to exception: /home/vmuser/.eclipse/org.eclipse.platform_4.4.1_2120408004_linux_gtk_x86_64/p2/org.eclipse.equinox.p2.engine/profileRegistry/_mnt_disk3_WindRiver_eclipse_e45rc3_64_committers-mars_eclipse.profile/.lock (Permission denied)

But the message itself indicates that this area is not writeable for the current user. 

So a basic question, is /home/vmuser the user.home for the admin user?

Also strange is that we guard the creation of the lazy registry using the org.eclipse.osgi.storage.StorageUtil.canWrite(File) method

	public static boolean canWrite(File installDir) {
		if (installDir.canWrite() == false)
			return false;

		if (!installDir.isDirectory())
			return false;

		File fileTest = null;
		try {
			// we use the .dll suffix to properly test on Vista virtual directories
			// on Vista you are not allowed to write executable files on virtual directories like "Program Files"
			fileTest = File.createTempFile("writtableArea", ".dll", installDir); //$NON-NLS-1$ //$NON-NLS-2$
		} catch (IOException e) {
			//If an exception occured while trying to create the file, it means that it is not writtable
			return false;
		} finally {
			if (fileTest != null)
				fileTest.delete();
		}
		return true;
	}

It tries to create a file in that directory and if that fails, would return false.   In that case this code would create a normal profile registry.

  public Object createService(IProvisioningAgent agent)
  {
    IAgentLocation location = (IAgentLocation)agent.getService(IAgentLocation.SERVICE_NAME);
    File directory = LazyProfileRegistry.getDefaultRegistryDirectory(location);
    boolean canWrite = StorageUtil.canWrite(directory);
    SimpleProfileRegistry registry = canWrite ? new LazyProfileRegistry(agent, directory) : new SimpleProfileRegistry(agent, directory);
    registry.setEventBus((IProvisioningEventBus)agent.getService(IProvisioningEventBus.SERVICE_NAME));
    return registry;
  }


So the two facts seem to contradict each other.  One test seems to indicate the folder is writeable, but later attempts to create a lock in that folder argue that the folder is not writeable.

What I'll do is add a system property that completely disables creating the lazy registry so you can test whether p2 itself works in this scenario.

Comment 16 Martin Oberhuber 2015-06-10 03:31:06 EDT

Yes, /home/vmuser is the read-only admin. The user is /folk/mober .

Comment 17 Ed Merks 2015-06-10 03:37:59 EDT

I've added support for the property oomph.p2.lazy.profile.registry, e.g, you can use -Doomph.p2.lazy.profile.registry=false in the eclipse.ini to disable the LazyProfileRegistry completely.

http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=13f88d76af6cb23104084b5fe7acc652babeb45b

Something seems contradictory here, but it will be good to investigate that when you can simply turn off the lazy profile completely.   Firstly, this seems to suggest that the read-only test returns an incorrect result, and secondly, we'd expect a profile registry that points at the user's writable folder.  This aspect (substituting the user's writeable configuration folder) is purely Equinox behavior and that seems to be behaving incorrectly from the traces you referred to...

Comment 18 Eike Stepper 2015-06-10 04:49:20 EDT

Hi Martin,

We've only a few hours left to get something into RC4 and it would be great if you could test again with the new option that Ed has added for you (see comment #17), so that we can see whether this is a problem that another project (platform, p2, ...) has introduced.

I've kicked a new build for you and it's available here:

https://hudson.eclipse.org/oomph/job/integration/lastSuccessfulBuild/artifact/products

Comment 19 Martin Oberhuber 2015-06-10 05:51:40 EDT

Created attachment 254282 [details]
Contents of $HOME/.eclipse after launch

(In reply to Ed Merks from comment #17)
Installed build #1432 (Jun10 5:15:58am) as vmuser, then launched as mober.
This is the error I get with -vmargs -Doomph.p2.lazy.profile.registry=false 

https://dev.eclipse.org/recommenders/community/confess/#/incidents/dnl1HDKrCTOzNh7rZevwmg05b0ik2lLfjdHFmn4mKDXg9iH4fURuB9SRQSaqP16V

FYI, for a 2nd test I removed all ~/.eclipse and after launching again it has this (full contents attached as dot_eclipse.zip) :

ls -la ~/.eclipse
drwxr-xr-x   6 mober users   4096 Jun 10  2015 .
drwxr-xr-x 148 mober t5-dev 16384 Jun 10  2015 ..
drwxr-xr-x   3 mober users   4096 Jun 10  2015 org.eclipse.oomph.p2
drwxr-xr-x   4 mober users   4096 Jun 10  2015 org.eclipse.oomph.setup
drwxr-xr-x   3 mober users   4096 Jun 10  2015 org.eclipse.platform_4.5.0_817489827_linux_gtk_x86_64
drwxr-xr-x   2 mober users   4096 Jun 10  2015 org.eclipse.recommenders

ls -la ~/.eclipse/org.eclipse.platform_4.5.0_817489827_linux_gtk_x86_64/configuration
drwxr-xr-x 10 mober users 4096 Jun 10  2015 .
drwxr-xr-x  3 mober users 4096 Jun 10  2015 ..
-rw-r--r--  1 mober users  104 Jun 10  2015 config.ini
drwxr-xr-x  3 mober users 4096 Jun 10  2015 org.eclipse.core.runtime
drwxr-xr-x  2 mober users 4096 Jun 10  2015 org.eclipse.e4.ui.css.swt.theme
drwxr-xr-x  3 mober users 4096 Jun 10  2015 org.eclipse.equinox.app
drwxr-xr-x  2 mober users 4096 Jun 10  2015 org.eclipse.oomph.setup
drwxr-xr-x  8 mober users 4096 Jun 10  2015 org.eclipse.osgi
drwxr-xr-x  2 mober users 4096 Jun 10  2015 org.eclipse.ui.intro.universal
drwxr-xr-x  2 mober users 4096 Jun 10  2015 org.eclipse.update
drwxr-xr-x  2 mober users 4096 Jun 10  2015 .settings

Comment 20 Ed Merks 2015-06-10 07:20:51 EDT

Thanks for taking the time to chat on Skype.

I'll resolve this as fixed given that an installer-produced installation, where bundle pooling is disabled, produces a result that does work as expected for other users.