Ticket #662 (new defect)
matlab from "MIT Software" does work, but hackishly
| Reported by: | geofft | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | The Distant Future |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
We made the matlab launcher start in a terminal to resolve #541; this ticket is here to track down the real issue. I'm not sure what it is -- there's a claim in the ticket that it's due to $ATHENA_SYS being unset, but a later one that it is in fact set, and another claim that it's due to -desktop being eaten, but the launcher does in fact start the desktop and /proc/$(pgrep MATLAB)/cmdline does not indicate -desktop (it's just 1/afs/.../unwrap /afs/.../MATLAB`).
I wonder if it's relevant that fds 0, 1, and 2 appear(ed) to be closed. MATLAB runs for a while and then terminates.
Change History
comment:2 Changed 13 years ago by kaduk
alexp had expressed some concern that nothing from the MIT software menu worked, but I confirmed on a real-live production machine that mathematica works, today.
Matlab, however, does not.
If I attempt to 'gathrun matlab matlab -desktop' manually, I see
w-a-thornhump-iii:~> gathrun matlab matlab -desktop wrapper(Matlab): server returned error: Key generator out of range
Which looks vaguely like an "out-of-licenses" error, but that seems odd for this time of IAP.
comment:3 Changed 13 years ago by kaduk
Alex points out (rightly) that thornhump is having time problems, so clock skew is to blame for that error.
On opus.mit.edu, wihch does not have clock skew, matlab from the MIT software menu does work. It also seems to work on lola-granola.mit.edu, which is running cluster from development. Maybe we just need to move stuff to production?
comment:4 Changed 12 years ago by jdreed
Right, ok, I did some debugging on this. The bug here is "MATLAB does not run when stdin is closed or not a tty", to which the upstream answer is almost certainly "You're right, it doesn't." This has nothing to do with the slw wrappers, because stock, locally-installed MATLAB (like, from the CD) also does not work when launched from a .desktop file.
I don't know what, if anything, the fix is, beyond what we've done.
I'll also note that "-desktop" appears to be the default in modern MATLAB, so probably "gathrun matlab matlab" is the right answer.
I just tried again today on a newly-upgraded W20-575 machine, and again MATLAB's stdout ended up in .xsession-errors, then it died (presumably from input starvation). So there may be something to your observation about closed file descriptors.
I say "again" because iirc this is what was happening before. atm, #541 is not closed for me.