Why does the `tcgetattr` error occur when ssh is used to dump the backup file to another server?

Question

I want to dump a backup of tables on another server, and I use ssh for this. when I run the command below it gives an error, but the dump file is copied to the destination.

mysqldump -u username -ppassword dbname tablename | ssh -t -t servers_username@domain _name 'cat > /tmp/bckp.sql'; 

tcgetattr: Invalid argument

If I press CTRL + c , then it adds an error message with Killed by signal 2.

Why is this a mistake?

Answer 1

I saw this error when forcing pseudo-terminal distribution using ssh -t -t or ssh -tt .

The tcgetattr function is used to search for attributes of a pseudo-terminal represented by a file descriptor; it takes a file descriptor and a pointer to a termios structure for storing terminal metadata. It seems to me from the stub code in glibc that this error is a null pointer to the termios structure. I'm not sure if these same error handling semantics exist for implementations of the tcgetattr platform.

If you want to suppress this error, call ssh like this:

 ssh 2>/dev/null 

This will redirect STDERR to /dev/null ; You will not see an error when calling with this redirect. Note that this will mask other errors using ssh ; you may need to remove this for debugging purposes.

Answer 2

In my case, forcing pty distribution on the external ssh of a two-level ssh call resolved the issue.

More details:

When you provide a command to start ssh (for example, ssh some_server "do_some_command"), then ssh assumes that you will not need an interactive session and it will not allocate pty, because it sends the job "do_some_command" that you set this to.

However, everything becomes interesting if you have two ssh levels (for example, let's say you want ssh to the “gateway” machine first, and from there you run ssh in the internal machine and run some “internal command”).

The fact is that with a two-layer ssh'ing job from the point of view of external ssh, you request that external ssh execute a non-interactive command, so external ssh does not allocate tty.

If the command that you run in internal ssh should be interactive, it will probably want to request tty attributes, and it (rightly) will tell you that it does not run on tty.

The solution in my case was to force external ssh to highlight pty using the -t argument. So it looked like this:

ssh -t <gateway_machine> "ssh <inner_machine> \" <inner_interactive_command> \ ""

Greetings to system administrators there