Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Problem

When running apt-get install in an 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.
share|improve this question
    
If you execute the install command manually (ie ssh user@target then the commands from the shell) does it work correctly? –  ring0 Mar 21 '13 at 7: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 7:50
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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 8:14
add comment

As I looked through it, this may do the job. Calling whatever command should be followed by exit and heredoc. Found the solutin but havent 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

Hope it helps.

share|improve this answer
    
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 7: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 8:09
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.