why is the `tcgetattr` error seen when ssh is used for dumping the backup file on another server?

Question

I want to dump a tables backup on another server and I am using ssh for doing it. when I run the below command, it gives an error but dump file is copied to 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 appends error message with Killed by signal 2.

Why is this error?

Answer 1

I've seen this error when forcing pseudo-terminal allocation using ssh -t -t or ssh -tt.

The tcgetattr function is used to look up the attributes of the pseudoterminal represented by a file descriptor; it takes a file descriptor and a pointer to a termios structure to store the terminal metadata in. It looks to me from the stub code in glibc that this error represents a null pointer for the termios struct. I am not sure whether these same error handling semantics are in place for the platform-specific implementations of tcgetattr.

If you want to suppress this error, invoke ssh like so:

ssh 2>/dev/null

This will redirect STDERR to /dev/null; you won't see the error when invoking with this redirection. Note that this will mask other errors with ssh; you may need to remove this for debugging purposes.

Answer 2

In my case, forcing pty allocation on the outer ssh of a two-level ssh invocation fixed the problem.

Details:

When you provide a command for ssh to run ( e.g. ssh some_server "do_some_command" ), then ssh assumes you won't need an interactive session, and it will not allocate a pty as it submits the "do_some_command" job you asked it to.

However, things get interesting if you have two layers of ssh (e.g. let's say you want to ssh into a "gateway" machine first, and from there you ssh into an "inner" machine and run some "inner_command").

The thing is, with a two-layer ssh'ing job, from the perspective of the outer ssh, you are requesting that the outer ssh run a non-interactive command, hence the outer ssh will not allocate a tty.

If the command you are running in the inner ssh is meant to be interactive, it will probably want to query tty attributes and it will (righteously) complain that it is not being run on a tty.

The solution in my case was to force the outer ssh to allocate a pty, by using the -t argument. So it looked like this:

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

Greetings to the sysadmins out there