New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploy freezes #1430

Open
dfridrich opened this Issue Nov 26, 2017 · 13 comments

Comments

Projects
None yet
6 participants
@dfridrich

dfridrich commented Nov 26, 2017

Q A
Issue Type Question
Deployer Version 6.0.3
Local Machine OS macOS 10.13.1 (High Sierra)
Remote Machine OS Debian Jessie 8.5

Description

Deployer is stucked during deploy:prepare command. I have tried multiplexing and forwardAgent combination true or false with no effect.

Steps to reproduce

dep deploy

Content of deploy.php

<?php
namespace Deployer;

require 'recipe/symfony3.php';

// Project name
set('application', 'hourglass');

// Project repository
set('repository', 'git@gitlab.com:xxx/hourglass.git');

// [Optional] Allocate tty for git clone. Default value is false.
set('git_tty', true); 

// Shared files/dirs between deploys 
add('shared_files', []);
add('shared_dirs', []);

// Writable dirs by web server 
add('writable_dirs', []);

// Hosts
host('access.snackhost.eu')
    ->user('xxx')
    ->configFile('~/.ssh/config')
    ->identityFile('~/.ssh/id_rsa')
//    ->multiplexing(true)
//    ->forwardAgent(false)
    ->port(22)
    ->set('deploy_path', '/home/xxx/deploys/hourglass');
    
// Tasks

task('build', function () {
    run('cd {{release_path}} && build');
});

// [Optional] if deploy fails automatically unlock.
after('deploy:failed', 'deploy:unlock');

// Migrate database before symlink new release.

before('deploy:symlink', 'database:migrate');

Output log

dep deploy -vvv
[localhost] > export SYMFONY_ENV='prod'; git rev-parse --abbrev-ref HEAD
[localhost] < master
✈︎ Deploying master on access.snackhost.eu
• done on [access.snackhost.eu]
➤ Executing task deploy:prepare
[access.snackhost.eu] > export SYMFONY_ENV='prod'; echo $0
[access.snackhost.eu] < bash
@antonmedv

This comment has been minimized.

Show comment
Hide comment
@antonmedv

antonmedv Nov 27, 2017

Member

Looks like your connected to server successfully:

[access.snackhost.eu] > export SYMFONY_ENV='prod'; echo $0
[access.snackhost.eu] < bash

But stuck after that. Can you give me access to your server to test it myself?

Member

antonmedv commented Nov 27, 2017

Looks like your connected to server successfully:

[access.snackhost.eu] > export SYMFONY_ENV='prod'; echo $0
[access.snackhost.eu] < bash

But stuck after that. Can you give me access to your server to test it myself?

@dfridrich

This comment has been minimized.

Show comment
Hide comment
@dfridrich

dfridrich Nov 27, 2017

@antonmedv, I change timeout to 2s, this is what I get:

[Symfony\Component\Process\Exception\ProcessTimedOutException]                                                                                  
The process "ssh -A -p 22 -i ~/.ssh/deploy -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no sepiasofteu@access.snackhost.eu  'bash -s; printf "[exit_code:%s]" $?;'" exceeded the timeout of 2 seconds.

When I try to run this command directly from CLI I get connected.

dfridrich commented Nov 27, 2017

@antonmedv, I change timeout to 2s, this is what I get:

[Symfony\Component\Process\Exception\ProcessTimedOutException]                                                                                  
The process "ssh -A -p 22 -i ~/.ssh/deploy -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no sepiasofteu@access.snackhost.eu  'bash -s; printf "[exit_code:%s]" $?;'" exceeded the timeout of 2 seconds.

When I try to run this command directly from CLI I get connected.

@danielchodusov

This comment has been minimized.

Show comment
Hide comment
@danielchodusov

danielchodusov Dec 8, 2017

Having exactly the same problem. @dfridrich did you manage how to fix it?

danielchodusov commented Dec 8, 2017

Having exactly the same problem. @dfridrich did you manage how to fix it?

@dfridrich

This comment has been minimized.

Show comment
Hide comment
@dfridrich

dfridrich Dec 9, 2017

@danielchodusov not yet, so I'm still using Capistrano :(

dfridrich commented Dec 9, 2017

@danielchodusov not yet, so I'm still using Capistrano :(

@antonmedv

This comment has been minimized.

Show comment
Hide comment
@antonmedv

antonmedv Dec 9, 2017

Member

Sorry, for delay. Did you solve problem?

Member

antonmedv commented Dec 9, 2017

Sorry, for delay. Did you solve problem?

@dfridrich

This comment has been minimized.

Show comment
Hide comment
@dfridrich

dfridrich commented Dec 9, 2017

@antonmedv nope :(

@antonmedv

This comment has been minimized.

Show comment
Hide comment
@antonmedv

antonmedv Dec 9, 2017

Member

Okay, lets try to investigate it. Please, contact me by email.

Member

antonmedv commented Dec 9, 2017

Okay, lets try to investigate it. Please, contact me by email.

@stefax

This comment has been minimized.

Show comment
Hide comment
@stefax

stefax Dec 21, 2017

I have the same issue as dfridrich ... running into the timeout (300 seconds) for a symfony-recipe based deployment. The task executed is "deploy:vendors". It doesn't happen regularily, one time the timeout happens, another time it's ok.

stefax commented Dec 21, 2017

I have the same issue as dfridrich ... running into the timeout (300 seconds) for a symfony-recipe based deployment. The task executed is "deploy:vendors". It doesn't happen regularily, one time the timeout happens, another time it's ok.

@aryaNmlp

This comment has been minimized.

Show comment
Hide comment
@aryaNmlp

aryaNmlp Dec 21, 2017

Can i tell a web to ask this question Google help forum

aryaNmlp commented Dec 21, 2017

Can i tell a web to ask this question Google help forum

@antonmedv

This comment has been minimized.

Show comment
Hide comment
@antonmedv

antonmedv Dec 21, 2017

Member

@stefax set global timeout:

set('default_timeout', 3400);
Member

antonmedv commented Dec 21, 2017

@stefax set global timeout:

set('default_timeout', 3400);
@staabm

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 21, 2017

Contributor

I can see rsync calls freezing after 100% compied and no further progress. with ssh -vv you can see

...
[ci16] < debug2: channel 2: rcvd adjust 98426
[ci16] < debug2: channel 2: rcvd adjust 98438
[ci16] < debug2: channel 2: rcvd adjust 98403
[ci16] < debug2: channel 2: rcvd adjust 98443
[ci16] < debug2: channel 2: rcvd adjust 98575
[ci16] < debug2: channel 2: rcvd adjust 98948
[ci16] < debug2: channel 2: rcvd adjust 98877
[ci16] < debug2: channel 2: rcvd adjust 98453
[ci16] < debug2: channel 2: rcvd adjust 98527
[ci16] < debug2: channel 2: rcvd adjust 98480
[ci16] < debug2: channel 2: rcvd adjust 98681
     23,197,244 100%   15.73MB/s    0:00:01 (xfr#1, to-chk=0/1)
[ci16] < debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
[ci16] < debug1: client_input_channel_req: channel 2 rtype eow@openssh.com reply 0
[ci16] < debug2: channel 2: rcvd eow
[ci16] < debug2: channel 2: close_read
[ci16] < debug2: channel 2: input open -> closed
[ci16] < debug2: channel 2: rcvd eof
[ci16] < debug2: channel 2: output open -> drain
[ci16] < debug2: channel 2: obuf empty
[ci16] < debug2: channel 2: close_write
[ci16] < debug2: channel 2: output drain -> closed
[ci16] < debug2: channel 2: rcvd close
[ci16] < debug2: channel 2: send close
[ci16] < debug2: channel 2: is dead
[ci16] < debug2: channel 2: gc: notify user
[ci16] < debug2: channel 1: rcvd close
[ci16] < debug2: channel 1: output open -> drain
[ci16] < debug2: channel 1: close_read
[ci16] < debug2: channel 1: input open -> closed
[ci16] < debug2: channel 2: gc: user detached
[ci16] < debug2: channel 2: is dead
[ci16] < debug2: channel 2: garbage collecting
[ci16] < debug1: channel 2: free: client-session, nchannels 3
[ci16] < debug2: channel 1: obuf empty
[ci16] < debug2: channel 1: close_write
[ci16] < debug2: Received exit status from master 0
[ci16] < debug2: channel 1: output drain -> closed
[ci16] < debug2: channel 1: is dead (local)
[ci16] < debug2: channel 1: gc: notify user
[ci16] < debug2: channel 1: gc: user detached
[ci16] < debug2: channel 1: is dead (local)
[ci16] < debug2: channel 1: garbage collecting
[ci16] < debug1: channel 1: free: mux-control, nchannels 2
[ci16] < debug2: set_control_persist_exit_time: schedule exit in 600 seconds
Contributor

staabm commented Dec 21, 2017

I can see rsync calls freezing after 100% compied and no further progress. with ssh -vv you can see

...
[ci16] < debug2: channel 2: rcvd adjust 98426
[ci16] < debug2: channel 2: rcvd adjust 98438
[ci16] < debug2: channel 2: rcvd adjust 98403
[ci16] < debug2: channel 2: rcvd adjust 98443
[ci16] < debug2: channel 2: rcvd adjust 98575
[ci16] < debug2: channel 2: rcvd adjust 98948
[ci16] < debug2: channel 2: rcvd adjust 98877
[ci16] < debug2: channel 2: rcvd adjust 98453
[ci16] < debug2: channel 2: rcvd adjust 98527
[ci16] < debug2: channel 2: rcvd adjust 98480
[ci16] < debug2: channel 2: rcvd adjust 98681
     23,197,244 100%   15.73MB/s    0:00:01 (xfr#1, to-chk=0/1)
[ci16] < debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
[ci16] < debug1: client_input_channel_req: channel 2 rtype eow@openssh.com reply 0
[ci16] < debug2: channel 2: rcvd eow
[ci16] < debug2: channel 2: close_read
[ci16] < debug2: channel 2: input open -> closed
[ci16] < debug2: channel 2: rcvd eof
[ci16] < debug2: channel 2: output open -> drain
[ci16] < debug2: channel 2: obuf empty
[ci16] < debug2: channel 2: close_write
[ci16] < debug2: channel 2: output drain -> closed
[ci16] < debug2: channel 2: rcvd close
[ci16] < debug2: channel 2: send close
[ci16] < debug2: channel 2: is dead
[ci16] < debug2: channel 2: gc: notify user
[ci16] < debug2: channel 1: rcvd close
[ci16] < debug2: channel 1: output open -> drain
[ci16] < debug2: channel 1: close_read
[ci16] < debug2: channel 1: input open -> closed
[ci16] < debug2: channel 2: gc: user detached
[ci16] < debug2: channel 2: is dead
[ci16] < debug2: channel 2: garbage collecting
[ci16] < debug1: channel 2: free: client-session, nchannels 3
[ci16] < debug2: channel 1: obuf empty
[ci16] < debug2: channel 1: close_write
[ci16] < debug2: Received exit status from master 0
[ci16] < debug2: channel 1: output drain -> closed
[ci16] < debug2: channel 1: is dead (local)
[ci16] < debug2: channel 1: gc: notify user
[ci16] < debug2: channel 1: gc: user detached
[ci16] < debug2: channel 1: is dead (local)
[ci16] < debug2: channel 1: garbage collecting
[ci16] < debug1: channel 1: free: mux-control, nchannels 2
[ci16] < debug2: set_control_persist_exit_time: schedule exit in 600 seconds
@stefax

This comment has been minimized.

Show comment
Hide comment
@stefax

stefax Dec 21, 2017

@antonmedv thanks, i will try with increased timeout. Additionally, I'll debug with --log deploy.log. I just learned about this awesome option...

stefax commented Dec 21, 2017

@antonmedv thanks, i will try with increased timeout. Additionally, I'll debug with --log deploy.log. I just learned about this awesome option...

@antonmedv

This comment has been minimized.

Show comment
Hide comment
@antonmedv

antonmedv Jan 26, 2018

Member

Also try to set controlpath to /dev/shm

Member

antonmedv commented Jan 26, 2018

Also try to set controlpath to /dev/shm

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