Replay/Debug container settings?

[javawolfpack]

Is the replay/debug container you can SSH into given more resources than the default? Curious as my run.py works perfectly when in the container in debug but not automatically for an assignment, so a bit perplexed about what is causing the issue. But differing resources might be a potential point to investigate, so I thought I'd ask.

[javawolfpack]

Is there something different that might impact signals? I maxed out the RAM that would let me to 8000MB for the environment, and it still times out as the assignment is a shell not sure if something is impacting signals. I don't think it's the case, but strangely, it evaluates fine when in the debug replay but not in the grading run.

[anthonygego]

In theory, when SSH debug is enabled, the hard timeout is set to 30min instead of the specified value, and that's the only difference for running the container. In practice, a few differences remain and come from the fact that the session is opened and the software is run through SSH.

The most common issue is that SSH tends to set a different shell environment to better fit your local settings. Therefore the set of environment variables may differ. Some graphical software that have CLI sometimes still look for the X display settings that may be sent through SSH, without using it.

There could also be subtleties if the software run has different behaviour in case no pseudo-TTY is attached or in a non-interactive shell and actually waits for something. Maybe you can get some insight by looking at the docker logs -f <the_container_id> when the container is running.

[javawolfpack]

So seem to have solved it. It seems adding start_new_session=True to the subprocess call in the run script for the few tests that were having issues resolved it. It likely was a side effect of Python not making a new gid when it spawned new processes with subprocess.