Ticket 8669

Summary: piped "srun --pty" failing pty setup
Product: Slurm Reporter: Jia Xin <alexjx>
Component: User CommandsAssignee: Jacob Jenson <jacob>
Status: RESOLVED INVALID QA Contact:
Severity: 6 - No support contract    
Priority: ---    
Version: 19.05.5   
Hardware: Linux   
OS: Linux   
Site: -Other- Alineos Sites: ---
Atos/Eviden Sites: --- Confidential Site: ---
Coreweave sites: --- Cray Sites: ---
DS9 clusters: --- HPCnow Sites: ---
HPE Sites: --- IBM Sites: ---
NOAA SIte: --- OCF Sites: ---
Recursion Pharma Sites: --- SFW Sites: ---
SNIC sites: --- Linux Distro: ---
Machine Name: CLE Version:
Version Fixed: Target Release: ---
DevPrio: --- Emory-Cloud Sites: ---
Attachments: Mimic the piped behavior of OpenSSH in srun

Description Jia Xin 2020-03-12 21:23:43 MDT
Created attachment 13366 [details]
Mimic the piped behavior of OpenSSH in srun

Hi,

Our user recently reported a case that they want to capture the full output of a program by pipe it's stdout to a file. However, the program required a PTY to run. 

It seems srun doesn't like the setup and complaining about it. Let's use bash as an example.

[centos@master1 ~]$ srun --pty bash -i | tee 1.log
srun: error: ioctl(TIOCGWINSZ): Invalid argument
srun: error: Not using a pseudo-terminal, disregarding --pty option
bash: cannot set terminal process group (-1): Invalid argument
bash: no job control in this shell
[centos@compute1 ~]$ 

I do get a bash running, however since the local pty was not set up correctly, I will lose some of the terminal functionalities. The setup, however, works with "ssh -t". 

There are a few things I learned from OpenSSH.

1. They are getting term information from STDIN fd instead of STDOUT in SLURM.
2. When fail to get the windows sizes from the fd, they just use value 0.

So this made me wonder if there is any special consideration that SLURM tries to handle it like it is now.

PS: I tried to mimic the behavior of OpenSSH. Patch attached.
But please advise if there anything I missed. Thanks.

Jia
Comment 1 Jia Xin 2020-03-13 20:31:31 MDT
Never mind.