System call bizarre behavior

I have a problem running Matlab 2017a on Centos 7. System/Unix calls will occasionally fail the first time they are called. The error received is "bang: poll [4] interrupted system call". The following call will then return the results of the proceeding call.

>> system('echo dogbone')
Error using system
Unexpected system error: bang: poll [4] Interrupted system call
>> system('echo dogbone1');
dogbone
>> system('echo dogbone2');
dogbone1
>> system('echo dogbone3');
dogbone2

I have never seen anything like this, and it's very frustrating. It only appears occasionally, but I can replicate it consistently by ssh-ing from another machine, like so:

ssh  -X user@machine 'matlab -nodesktop'

Any Thoughts?

Answer 1

[Michael Pelletier]

I found the root cause of this via an strace of the MATLAB process. It revealed this tidbit shortly after the attempt to run the first system() invocation:

553435 ioctl(3, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [553435]) = -1 ENOTTY (Inappropriate ioctl for device)

The "ENOTTY" means that the ioctl() call is inapplicable because the session is not associated with a pseudo-tty. And the reason that a poll() error comes back is because the thread reporting the error is not the one actually doing the fork/exec - it just sent a message to the thread that does. And so when the fork/exec thread fails, the poll() waiting for the response from that thread is interrupted.

The fix is to use the "-t" option for SSH, that is:

ssh -t -X user@machine 'matlab -nodesktop'

This forces the SSH server to allocate a pseudo-tty to the MATLAB process' environment whether it thinks it needs it or not, and so the ENOTTY error is avoided, and so allows the first system() call, and all subsequent system() calls, to work as expected.

Answer 2

[Sharath Chandran]

Hi Paul,

Could you please try sourcing .bash_profile prior to calling MATLAB?

If you are trying to launch MATLAB remotely on a different machine, then I would suggest you to try following:

$ ssh -l user@remoteSystem /bin/bash -c "matlab -nodisplay -nodesktop -noFigureWindows -r testScript.m"

where 'testScript.m' contains the command : system('echo dogbone'). Probably specifying the shell name, like above, works (since it reads .bash_profile while logging in using bash shell).

The difference probably is whether bash is in login mode or interactive mode (when .bash_profile is read) when invoking MATLAB in remote workflow.

I hope this helps.

Regards,

MathWorks Technical Support

[Michael Pelletier]

What information or service is MATLAB looking to obtain from the shell? Are there environment variables it's looking for, etc? This seems to be a change of behavior from prior releases - we've been running tens of thousands of MATLAB distributed compute jobs in a compute cluster without a shell for years.

Answer 3

[Jordan]

I obtain this same behaviour when I launch matlab and make system() calls within a VNC session, then ssh into my server from a different machine to check on how my system() job is going in the VNC session. Doing so causes an error in whatever job was running in the interactive matlab shell.

"Unexpected system error: bang: poll [4] Interrupted system call"

...followed by the same bizarre behaviour reported above. I am running Matlab 2017a on Ubuntu 16.04.3.

Answer 4

[Michael Pelletier]

This problem also plagues my code to submit HTCondor jobs from Windows machines, because it uses SSH to reach a machine where it can run condor_submit, if HTCondor is not installed on the Windows machine. If there's no answer to this, looks like I may be forced to do a try/catch along with a dummy second call to get any results, such as the job ID number.

Answer 5

[Max Rudolph]

I am having this problem as well, and it renders MATLAB essentially useless for common tasks that require me to invoke an external program. I also have R2017a on Ubuntu 18 LTS. I have additional, even more bizarre behavior. Sometimes MATLAB cannot find files in the cwd the first time, but they appear by running 'ls' twice: >> ls geoid.ab >> ls geoid.ab geoid.ab

>>