Perché Fabric lancia "TypeError: l'argomento deve essere un int, o avere un metodo fileno()"?

Question

Quando si esegue un compito tessuto su un server remoto ottengo il seguente stack trace:

[x.x.x.x] run: git fetch && git reset --hard origin/develop 
Exception in thread Thread-2: 
Traceback (most recent call last): 
    File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner 
    self.run() 
    File "/var/lib/jenkins/jobs/deploy/workspace/.pyenv/lib/python2.6/site-packages/ssh/agent.py", line 115, in run 
    self._communicate() 
    File "/var/lib/jenkins/jobs/deploy/workspace/.pyenv/lib/python2.6/site-packages/ssh/agent.py", line 125, in _communicate 
    events = select([self._agent._conn, self.__inr], [], [], 0.5) 
TypeError: argument must be an int, or have a fileno() method. 

Il fatto che il compito del tessuto sta tentando di eseguire un git recuperare e che le eccezioni è cresciuto a ssh/agente .py mi fa pensare che qualcosa non va con l'autenticazione SSH.

Lo stesso utente può eseguire git fetch al di fuori di Fabric e l'attività viene eseguita correttamente sul mio laptop.

Cosa sta succedendo qui? Come posso risolvere questo problema?

Answer 1

An issue generato sul tracker di problemi di Fabric accenna all'errore che potrebbe derivare dal non avere ssh-agent in esecuzione sull'host.

ho risolto il problema avviando uno ssh-agent e aggiungendo la chiave dell'utente:

$> eval `ssh-agent` 
$> ssh-add ~/.ssh/id_rsa 

successo!

Answer 2

Per auto-start ssh-agent quando in primo login, aggiungere questo al vostro ~/.bashrc:

if [ ! -S ~/.ssh/ssh_auth_sock ]; then 
    eval `ssh-agent` 
    ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock 
    ssh-add 
fi 
export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock 

Answer 3

mi sono imbattuto in questo errore durante l'utilizzo di tessuto con Python/Django, quando stavo cercando di eseguire compiti a mano entro ./manage.py shell_plus.

Si scopre (per me) che l'errore è stato causato dal fatto che il mio shell_plus è stato impostato per utilizzare bpython anziché ipython.

Quando ho eseguito ./manage.py shell_plus --ipython, invece, tutto ha funzionato perfettamente.

Mi rendo conto che probabilmente non è stata una risposta diretta al tuo problema, ma immagino che potrei anche lasciare una nota qui per chiunque altro accada sul problema come ho fatto io.