14

Problem

When running apt-get install in an non-interactive SSH session, the session never closes. Example:

ssh user@target "sudo apt-get -y install my_package"

The my_package does get installed properly, but the SSH session just dangles open.

Question

Is there any flag to pass SSH to get apt-get to work?

Additional Information

Context

Remote installation is used for automated deployment of a package on an integration server. As soon as we push some code changes to a repository, a job pulls in the code, builds the package, and deploys it on integration to check that everything works well (as far as deployment is concerned).

Already Tried & Notes

  • The same SSH session executing apt-get update closes cleanly. Note that apt-get update is not interactive, whereas apt-get install is. This may suggest that interactivity is an issue.
  • A command like ssh user@target "sudo apt-get install my_package && echo Hello" never reaches the echo.
  • debconf complains that it cannot find a nice frontend (Display, Readline), and it falls back to Teletype (although Readline is available).
  • In relation to debconf's frontend, passing -t to force TTY with SSH does not help. Neither DEBIAN_FRONTEND=noninteractive.
  • All was done on Ubuntu 12_04 LTS.
Eric Platon
  • 367
  • 2
  • 14
  • If you execute the install command manually (ie `ssh user@target` then the commands from the shell) does it work correctly? – Déjà vu Mar 21 '13 at 07:38
  • The install command just works fine when done manually (thus leading to think there is a problem with non-login/interactive session types). – Eric Platon Mar 21 '13 at 07:50

3 Answers3

6

The following answer on SF did the trick:

ssh fails to execute remote command when run from cron bash script

The -t flag forces a pseudo-tty allocation, except perhaps when there is no TTY locally. But passing the flag twice like in -t -t just pretends to do it. And that solved the problem.

See the SSH documentation:

-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.

Now, why did that work? It turns out that debconf does not complain anymore about the frontend in the logs. So I believe that the double -t sets (lures?) debconf as needed, which allows apt-get install completion to end the SSH session cleanly.

Community
  • 1
Eric Platon
  • 367
  • 2
  • 14
  • I believe this is a good answer, but I will not mark it immediately as is. First because I replied myself, and second, there might be better/more generic answers. Back on this in the future. – Eric Platon Mar 21 '13 at 08:14
1

As I looked through it, this may do the job. Calling whatever command should be followed by exit and heredoc. Found the solution, but haven't tried it personally.

ssh user@myremotemachine <<-EOF
free -m
exit
EOF

Original answer comes from here: http://www.thetechrepo.com/main-articles/529-execute-a-command-remotely-over-ssh-and-then-close-the-connection

Eric Platon
  • 367
  • 2
  • 14
koressak
  • 176
  • 5
  • Thank you, koressak. I guess this depends on the shell and the OS distribution. I have just tried `ssh user@host free -m` in my target environment, and it works like a charm. I am going to try the recommendation next. – Eric Platon Mar 21 '13 at 07:54
  • I have just tried a complete run with the heredoc approach. That did not solve the problem. The SSH session hangs the same way as presented in the question. Thanks again for the response and the pointer! – Eric Platon Mar 21 '13 at 08:09
1

Under debian/jessie I was successful with this command:

ssh user@host "TERM=READLINE sudo apt-get install --reinstall less && echo done"

But perhaps you should consider to use ansible for this and other upcomming tasks http://docs.ansible.com/ansible/apt_module.html

ThorstenS
  • 3,084
  • 18
  • 21
  • Interesting, good idea. As for Ansible, perhaps now. I do not know back when the question came to mind. Anyway, I believe it's good to know "what's happening inside"(c). – Eric Platon Mar 07 '16 at 10:04