deploy option 'needs_tty' fails with "Pseudo-terminal will not be allocated because stdin is not a terminal." #2231

Closed
mozeryansky opened this Issue Jun 19, 2016 · 10 comments

Comments

3 participants
@mozeryansky

What I'm attempting to do is run su in a post-deploy. To do this, I know I need a tty which is achieved with -t. I found in the source of deploy that if I include needs_tty then a -t will be used on the ssh commands for deploy. However, when I do this, all the ssh commands output "Pseudo-terminal will not be allocated because stdin is not a terminal."

I believe this is because the deploy command is passed the config string by piping in the string, instead of passing it as an argument.

Environment info

Operating System: OS X 10.11.5
Pm2 version: 1.1.3
Node version: 5.3.0
Shell: bash

Steps to reproduce

  1. In the ecosystem.json file include in the deploy section: "needs_tty": "yes". I don't think this was documented but I found in the source that it will add -t when doing ssh commands, which I need.
  2. Run deploy: pm2 deploy production

Logs

The pm2 log doesn't apply here, so this is from '/tmp/pm2-deploy.log'. From the logs, it looks like everything is operating correctly.

ssh -t username@website.com "cd /home/bob/source && git fetch --all"
ssh -t username@website.com "cd /home/bob/source && git reset --hard origin/master"
ssh -t username@website.com "ln -sfn /home/bob/source /home/bob/current"
ssh -t username@website.com "cd /home/bob/source && echo git rev-parse --short HEAD >> /home/bob/.deploys"
ssh -t username@website.com "cd /home/bob/current; SHARED="/home/bob/shared" su bob pm2 startOrRestart ecosystem.json --env production 2>&1 | tee -a /tmp/pm2-deploy.log; exit ${PIPESTATUS[0]}"

@mozeryansky

This comment has been minimized.

Show comment
Hide comment
@mozeryansky

mozeryansky Jun 19, 2016

If I change deploy.js to send the hostJSON as the first param, then in the deploy bash script replace 'read conf' with 'conf=$1; shift'. This will not open ssh with stdin and the commands will work.

If I change deploy.js to send the hostJSON as the first param, then in the deploy bash script replace 'read conf' with 'conf=$1; shift'. This will not open ssh with stdin and the commands will work.

@soyuka

This comment has been minimized.

Show comment
Hide comment
@soyuka

soyuka Jun 20, 2016

Collaborator

ping @Unitech I'm a bit lost on this one :|

Collaborator

soyuka commented Jun 20, 2016

ping @Unitech I'm a bit lost on this one :|

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Dec 6, 2016

Collaborator

Actually you can't use TTY with pm2 deploy since the binary is spawn by a shellscript.
I advise you to resolve the need for a su, it will be simpler.

Collaborator

vmarchaud commented Dec 6, 2016

Actually you can't use TTY with pm2 deploy since the binary is spawn by a shellscript.
I advise you to resolve the need for a su, it will be simpler.

@vmarchaud vmarchaud closed this Dec 6, 2016

@mozeryansky

This comment has been minimized.

Show comment
Hide comment
@mozeryansky

mozeryansky Dec 8, 2016

@vmarchaud I was able to get it to work with the fix I mentioned.

I do agree that I shouldn't be using su and I'm doing something else to accomplish what I wanted, but the current mode that pre/post deploy runs in is not what I would expect.

@vmarchaud I was able to get it to work with the fix I mentioned.

I do agree that I shouldn't be using su and I'm doing something else to accomplish what I wanted, but the current mode that pre/post deploy runs in is not what I would expect.

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Dec 8, 2016

Collaborator

I'm writing a new version of the deploying system (here) and i'll be happy if you provide me what you exactly expect from the pre/post hooks ?

Collaborator

vmarchaud commented Dec 8, 2016

I'm writing a new version of the deploying system (here) and i'll be happy if you provide me what you exactly expect from the pre/post hooks ?

@mozeryansky

This comment has been minimized.

Show comment
Hide comment
@mozeryansky

mozeryansky Dec 10, 2016

Thanks for following up. I would expect that whatever I put in the string of a hook can be executed as if I put that same string in the shell. I haven't modified my deployment, but when I was writing it, I was able to do everything except what I mentioned in my original comment. I'm very glad you're adding more hooks, it was confusing what ran where before.

Thanks for following up. I would expect that whatever I put in the string of a hook can be executed as if I put that same string in the shell. I haven't modified my deployment, but when I was writing it, I was able to do everything except what I mentioned in my original comment. I'm very glad you're adding more hooks, it was confusing what ran where before.

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Dec 10, 2016

Collaborator

@mozeryansky Actually i'm not just adding hooks, i'm rewriting it from scratch with a pure javascript solution without relying on a shellscript or spawning the ssh binary. I'm interested for feedback on it btw

Collaborator

vmarchaud commented Dec 10, 2016

@mozeryansky Actually i'm not just adding hooks, i'm rewriting it from scratch with a pure javascript solution without relying on a shellscript or spawning the ssh binary. I'm interested for feedback on it btw

@mozeryansky

This comment has been minimized.

Show comment
Hide comment
@mozeryansky

mozeryansky Dec 11, 2016

@vmarchaud I do see all the additional features, the limited number of hooks was a pain point in the current deployment tool. Personally, and on any project, if I'm using a tool (pm2) and that tool provides other related tools (pm2-deploy) I will almost always use that tool without looking for another (even if others have a million more features). I'm focussing on my project and trying out various deployment takes time away from that. Thank you for making a better tool though, not everyone works like I do.

mozeryansky commented Dec 11, 2016

@vmarchaud I do see all the additional features, the limited number of hooks was a pain point in the current deployment tool. Personally, and on any project, if I'm using a tool (pm2) and that tool provides other related tools (pm2-deploy) I will almost always use that tool without looking for another (even if others have a million more features). I'm focussing on my project and trying out various deployment takes time away from that. Thank you for making a better tool though, not everyone works like I do.

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Dec 11, 2016

Collaborator

@mozeryansky Yeah totally (same for me), but deployerjs will replace pm2-deploy as some point, thats the aim of deployerjs since the start.

Collaborator

vmarchaud commented Dec 11, 2016

@mozeryansky Yeah totally (same for me), but deployerjs will replace pm2-deploy as some point, thats the aim of deployerjs since the start.

@mozeryansky

This comment has been minimized.

Show comment
Hide comment

Ok great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment