Change .felix OSGi cache directory

When we use the figure command in Matlab there is a directory created called /tmp/.felix/ and our /tmp file system is very small so sometimes it fills up causing errors. Is there a way to direct Matlab to create that directory somewhere else?

[Walter Roberson]

Odd. Are you knowingly calling upon Java functionality? Or are you calling upon the built-in web browser, perhaps fetching web pages and manipulating the model of them?

Have you tried just making /tmp/.felix a symbolic link to somewhere else?

[Michael Robbert]

I believe that the figure function does call on Java functionality. I'm unable to use it if I try to start Matlab with the -nojvm option. Maintaining a symlink in this environment wouldn't be easy. This is being run on nodes in a shared HPC cluster. The nodes boot stateless and /tmp is mounted as a tmpfs volume. I supposed I could put something in my boot scripts to create the link, but I'd prefer to find a solution within Matlab.

[Walter Roberson]

MATLAB graphics does make extensive use of java, but the .felix directory is associated with a component model for java plug ins and the like, which I would not expect to be used by ordinary graphics.

[Michael Robbert]

When I run matlab (R2016b) on our cluster and just call 'figure;' I get a /tmp/.felix/osgi-cache* directory with 42 'bundle' directories under. The size isn't very large, but the user that is having the problem is calling figure inside of a parfor loop so they are getting 12 of the osgi-cache* directories. That is enough to fill up our tiny /tmp. Ultimately my problem is that all those cache files get left there and our nodes get taken offline to prevent problems for other users until I get around to rebooting to clear them out.

[Michael Robbert]

One other thing that I just discovered is that if a .felix directory already exists in /tmp/ from another user and that directory isn't writable by the current user then Matlab will happily create or use a .felix in the current users home directory. So, I have another work around if I want to maintain files in the /tmp directories of all of my nodes. I just feel like there should be some environmental variable that I can use to alter this behavior. Yes, I have tried setting TMP and that does not appear to affect this.

[Walter Roberson]

http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.html

[Walter Roberson]

Let me think... You are using Linux. I wonder if this is a behavior triggered by whatever opengl you are using? Are you using a vendor opengl, or one of the Linux software opengl?

[Michael Robbert]

We don't have any special graphics cards in these nodes nor any specific OpenGL drivers installed so I'm guessing it is standard Linux software OpenGL.

I have also looked at the Apache Felix documentation and haven't been able to find a way for me to alter its behavior. I don't have control over the Java execution arguments and I can't find any existing properties files in my Matlab install tree.

If it is helpful here is the first error that was thrown on one of my attempts.

org.osgi.framework.BundleException: Unable to cache bundle: reference:file:/gpfs/sb/mio/opt/com/MATLAB/R2016b/java/jar/addons_toolbox.jar
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2070)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2026)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:130)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:108)
        at com.mathworks.util.osgi.OSGiManager.installBundles(OSGiManager.java:247)
        at com.mathworks.util.osgi.OSGiManager.getBundles(OSGiManager.java:235)
        at com.mathworks.util.osgi.OSGiManager.getInstalledBundles(OSGiManager.java:95)
        at com.mathworks.util.osgi.ClasspathOSGiManager.getInstalledBundles(ClasspathOSGiManager.java:56)
        at com.mathworks.services.binding.MatlabKeyBindings.readActionAndContextFilesFromOSGi(MatlabKeyBindings.java:624)
        at com.mathworks.services.binding.MatlabKeyBindings.<clinit>(MatlabKeyBindings.java:592)
        at com.mathworks.widgets.action.BaseAbstractAction.<init>(BaseAbstractAction.java:24)
        at com.mathworks.widgets.action.AbstractNewAction.<init>(AbstractNewAction.java:24)
        at com.mathworks.hg.peer.FiguresGroup$NewFigureAction.<init>(FiguresGroup.java:78)
        at com.mathworks.hg.peer.FiguresGroup.createToolBar(FiguresGroup.java:68)
        at com.mathworks.hg.peer.FiguresGroup.<init>(FiguresGroup.java:43)
        at com.mathworks.hg.peer.FiguresGroup.getInstance(FiguresGroup.java:52)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.mathworks.widgets.desk.DTGroup.createPropertyProvider(DTGroup.java:253)
        at com.mathworks.widgets.desk.DTGroup.getPropertyProvider(DTGroup.java:190)
        at com.mathworks.widgets.desk.DTOccupant.getProperty(DTOccupant.java:748)
        at com.mathworks.widgets.desk.DTOccupant.getToolstripTabs(DTOccupant.java:520)
        at com.mathworks.widgets.desk.DTGroup.add(DTGroup.java:349)
        at com.mathworks.widgets.desk.Desktop.addClient(Desktop.java:6623)
        at com.mathworks.widgets.desk.Desktop.addClient(Desktop.java:6590)
        at com.mathworks.widgets.desk.Desktop.addSingletons(Desktop.java:5657)
        at com.mathworks.mde.desk.MLDesktop.<init>(MLDesktop.java:555)
        at com.mathworks.mde.desk.MLDesktop.getInstance(MLDesktop.java:616)
        at com.mathworks.mde.desk.MLDesktopRegistrar.getDesktop(MLDesktopRegistrar.java:11)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.mathworks.mlservices.MLServices.getRegisteredService(MLServices.java:29)
        at com.mathworks.mlservices.MatlabDesktopServices.<clinit>(MatlabDesktopServices.java:14)
        at com.mathworks.hg.peer.FigureClientProxy.getMatlabDesktop(FigureClientProxy.java:504)
        at com.mathworks.hg.peer.FigureClientProxy.<init>(FigureClientProxy.java:92)
        at com.mathworks.hg.peer.HG2FigureClientProxy.<init>(HG2FigureClientProxy.java:20)
        at com.mathworks.hg.peer.FigureHG2Mediator.<init>(FigureHG2Mediator.java:43)
        at com.mathworks.hg.peer.HG2FigurePeer.createFigureClient(HG2FigurePeer.java:74)
        at com.mathworks.hg.peer.FigurePeer.doInitializePeer(FigurePeer.java:454)
        at com.mathworks.hg.peer.FigurePeer$2.run(FigurePeer.java:419)
        at com.mathworks.jmi.AWTUtilities$Invoker$5$1.run(AWTUtilities.java:591)
        at com.mathworks.mvm.context.ThreadContext$1.call(ThreadContext.java:76)
        at com.mathworks.mvm.context.ThreadContext.callWithContext(ThreadContext.java:105)
        at com.mathworks.mvm.context.ThreadContext.runWithContext(ThreadContext.java:73)
        at com.mathworks.mvm.context.MvmContext.runWithContext(MvmContext.java:107)
        at com.mathworks.jmi.AWTUtilities$Invoker$5.runWithOutput(AWTUtilities.java:588)
        at com.mathworks.jmi.AWTUtilities$Invoker$2.watchedRun(AWTUtilities.java:475)
        at com.mathworks.jmi.AWTUtilities$WatchedRunnable.run(AWTUtilities.java:436)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$200(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: No space left on device

There are several of these all from jar files under the Matlab install tree.

[Walter Roberson]

Yep, that is clearly MATLAB triggering the install.

I think you are going to need to open a support case about this.

[Gregory]

Is there any reason to keep this files not delete. Perhaps making the delete automatic?

[Michael Robbert]

Gregory, That is a good question for the folks at Matlab. I presume, given the name implies it is a cache, that there is some performance benefit for keeping it around at least within a single session. While looking it up using Google I found references to its use outside of Matlab and if I recall correctly some people indicated that it had long term usefulness, but in our use case which is a shared cluster we can't have it persisting on local disks so we do clean up at the end of the users session. My original problem was that it was actually filling up a local partition thereby causing other problems.

Answer 1

[Michael Robbert]

I contacted support and was given a list of variables and properties that are checked in order for a valid place to put this cache along with some suggestions on how to set it up. Here is an excerpt from that response that gives the list: There are a few locations where MATLAB will try to create this cache, in order of precedence (where MATLAB will try the next option if the specified variable is not set or the location which it specifies is not writable by the user who is running MATLAB):

 - Directory specified by environment variable TMPDIR
 - Directory specified by environment variable TMP
 - Directory specified by environment variable TEMP
 - Directory specified by Java property java.io.tmpdir
 - Directory specified by environment variable HOME
 - Directory specified by Java property user.home

Changing the TMPDIR variable to a different path would resolve the issue. However I would not suggest doing that as it might temper with the other processes that use the /tmp to store the temporary files.

What I would suggest is setting this variable 'TMPDIR' only in a given MATLAB session. This can be don by setting this variable in "startup.m" and resetting it back in "finish.m".

[Walter Roberson]

If you set it using setenv() then it only applies to the current process and children, and there would be no need to set it back in finish.m