Ticket #541 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

matlab from "MIT Software" does not work

Reported by: kaduk Owned by:
Priority: normal Milestone: Summer 2010 (Lucid Deploy)
Component: development Keywords:
Cc: alexp Fixed in version:
Upstream bug:


If I run Applications->MIT Software->MATLAB, (after some delay), I get a splash screen, some more delay, and then nothing. (The MATLAB process terminates.)
If I 'athrun matlab' manually from a terminal, I get a text-mode matlab window, but no sign of a GUI.

This was reported by a user on -cluster, but my report is from -workstation.

Change History

comment:1 Changed 12 years ago by jdreed

This is almost certainly due to the fact that ATHENA_SYS isn't set. I think there may be some other things missing from the environment that gathrun is executed in (I'm not in front of a workstation at the moment), but some Athena-specific environment variables are still present.

We could patch gathrun, but we probably want to know why the panel is running things in a weird environment.

comment:2 Changed 12 years ago by jdreed

  • Priority changed from minor to major
  • Milestone set to Spring 2010

comment:3 Changed 12 years ago by jdreed

So, something special is going on here:

  • I consistently see ATHENA_SYS unset when running something from the panel. This happens under other accounts. It's possible it's limited to accounts that don't have bash as their shell, but it's not clear.
  • libathdir's compiled-in value of ATHSYS is wrong, because it's not set in the build chroots.

One fix here is to have libathdir build-depend on machtype, and use that to set ATHENA_SYS at build time.

comment:4 Changed 12 years ago by jdreed

  • Milestone changed from Spring 2010 to Summer 2010 (Lucid Deploy)

comment:5 Changed 12 years ago by jdreed

Well, we should fix libathdir anyway, but that won't fix this ticket, because otherwise we wouldn't even get the splash screen.

comment:6 follow-up: ↓ 8 Changed 12 years ago by jdreed

Matlab is in fact running in tty mode, though it's unclear why. If you edit gathrun to have it exec 2>&1 > /tmp/log, you can see that the MATLAB terminal prompt is getting sent to stdout, right before it presumably dies because there's no controlling tty.

A short-term fix is to change the launchers to "Application in Terminal"

comment:7 Changed 12 years ago by alexp

  • Cc alexp added

Matlab is in fact running in tty mode, though it's unclear why.

The default launch was set to tty mode because when the Desktop first came out years ago, many MIT users expressed a strong dislike for it and asked that the old-style tty mode launch be kept the default.


comment:8 in reply to: ↑ 6 Changed 12 years ago by andersk

Replying to jdreed:

exec 2>&1 > /tmp/log

You mean exec > /tmp/log 2>&1, BTW.

comment:9 Changed 12 years ago by kcarnold

A friend just asked me about this today, and I can confirm it still doesn't work.

The MATLAB startup messages are ending up in ~/.xsession-errors. Trying to watch ps output shows that the '-desktop' option is getting eaten somewhere in the startup handoff. I can only reliably get two sample points in the process:

Has -desktop:
perl /mit/matlab_v7.9/arch/i386_deb50/bin/matlab -desktop

... no -desktop:
/afs/athena/system/slw/unwrap /afs/athena.mit.edu/software/matlab_v7.9/distrib/bin/glnx86/MATLAB

I can run the former command in a shell with a whole bunch of Athena environment variables unset, and it complains a bit but successfully launches a MATLAB desktop.

comment:10 Changed 12 years ago by kaduk

Had a user come into SIPB asking about matlab, today; I gave him 'gathrun matlab matlab -desktop', which I think worked for him.

comment:11 Changed 12 years ago by jdreed

  • Status changed from new to proposed

Temporarily switched it to run in a Terminal, because this is actively screwing users. We should debug argument lossage and actually fix it, however.

comment:12 Changed 12 years ago by geofft

  • Status changed from proposed to closed
  • Resolution set to fixed

Tested, seems to work modulo the unsightly extra terminal, moved to production, filed #662 to track down the real issue.

Note: See TracTickets for help on using tickets.