On 8/13/07, James Snyder <jbsnyder@xxxxxxxxx> wrote:
> Hi -
>
> I initially had some great success with getting MATLAB compiler compiled
> code (using lcc), but lately I'm having trouble with the jobs that have been
> submitted running on remote WinXP hosts.
>
> The main error I'm currently getting back is "??? Undefined function or
> variable 'matlabrc'."
>
> Some machines are also giving me:
> Could not create directory: 'C:\Documents and Settings\Default
> User\Application
> Data\MathWorks\MATLAB\mcr_v75\main_6C985847B4BE48E9B6364FFEB5FFBE97'
> ??? Undefined function or variable 'matlabrc'.
>
> I don't understand why it would be attempting to write out to this location
> on the C: drive.
It is following the windows dev guidelines for where to put
application data which should not be user visible but may need to be
persisted across sessions.
This would conceptually be %APPDATA%\CompanyName\AppName but in fact
should be located in code by the Shell32 api SHGetFolderPath().
I do not know if this respects changes to the environment variable (I
doubt it - though screwing with the registry might work).
If you can handle it security wise is is probably ok to give all local
users the relevant rights this area. Better still would be to
pre-create the MathWorks\MATLAB directory for the default user and
give all local users Create Folders/Append Data rights. (this assumes
you can pre-setup all your submit machines)
I'll try pre-creating this directory on machines I've got control over. It would still be optimal to get the compiled executable/matlab libraries to re-direct things to the temp space being used by the compiled executable. I don't suppose there's a windows equivalent to jailing an environment as on Linux/BSD? I'd like it if the setups/installs could be as minimal as possible on the machines that things are being set up on (they're machines in computer labs).
> And the bat file I'm using to get things up and running (the MCR libraries
> are served from a Linux host running samba):
> set
> net use m: \\<removed>\lab_bin /USER:condor /PERSISTENT:no <removed>
The following should work fine
> set PATH=m:\extrabin\win32\mcr\v75\runtime\win32;%PATH%
> set TMPDIR=%_CONDOR_SCRATCH_DIR%
> set TMP=%TMPDIR%
But I think these stand a good chance of not
Yeah, as noted, it didn't seem to respect these changes.
> set APPDATA=%TMPDIR%
> set ALLUSERSPROFILE=%TMPDIR%
> I added the APPDATA and ALLUSERSPROFILE hoping to prevent it from trying to
> write to the default user app data directory, no joy there. Any
> suggestions? The compiled exe file works just fine when run locally on a
> machine.
Basically it's a perms thing. By default I do not know if XP gives
Everyone the perms required.
On my machine "Everyone" does not have Create Folders/Append Data nor
Create Files on the root of AppData in Default User (nor for that
matter in a random selection of the sub folders that exist). My perms
may not be the defaults however.
I'm not 100% clear on how condor sets up credentials other than indicating that they are indicated as being "bare bones" in the manual. I think some of the lab administrators who are willing to share their lab resources might not like the concept of giving Everyone write access to something new. I'll see if making these tweaks makes a difference however.
You may be able to run matlab in a way that doesn't try to write the
data it is trying to store (again I have no idea how). using
RunAsOwner with the relevant credential setup should also fix it since
you should stop using the Default User directory...
Based on the docs, I will assume that this means making an account on the destination machine that matches up with the submitting user (to RunAsOwner). Really, I don't mind if the compiled job writes out this data, so long as it is in either the temporary area created in c:\condor\execute or on the shared drive I've mounted.
Re Nicola:
I think I've got the appropriate PATH definitions. I'd like to avoid doing a full MCR install on the machines, and if I run as a real user on a target machine, using MCR libraries from the shared drive does appear to work. From the page in your most recent response it looks like the problem is that it is trying to expand the preferences directory out into default user directory. I wonder if there's a way to re-align that?
Re Simon:
Between your and Nicola's reply I think I now understand the error. Question is, is there an easy way to redirect that preferences directory to a new location? Condor starts a job up as a minimal user, and I wouldn't mind keeping it in that shell. Hopefully I won't need to give jobs any more privs than they already get.
Re Ali:
Hope this discussion helps :-)
Matt
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}