Ludovic Courtès skriver: > Hi, > > Andrew Tropin skribis: > >>>> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >>>> Throw to key `guile-ssh-error' with args `("channel-open-session" "Channel opening failure: channel 67 error (2) open failed" # #f)'. >>> >>> Are there any hints from sshd in the /var/log/messages of that machine >>> as to why the connection was closed? >> >> bob@pinky /var/log$ zcat messages.1.gz | grep "Oct 4" | grep ssh > > It’s hard (if not impossible) to see which lines correspond to the error > above. :-) > > Could try to reproduce the bug, and have ‘tail -f /var/log/messages’ > running on the server side so you can capture just the right lines? > /var/log/debug might be interesting too. I have the same problem. Log messages around failure look something like this (extracted from above message): Oct 4 11:51:49 localhost shepherd[1]: Service sshd-2 has been started. Oct 4 11:51:50 localhost sshd[250]: Accepted publickey for bob from 185.70.53.164 port 1915 ssh2: RSA SHA256:/X3jyhyMizAOKOjCfXK5cLN3Pa0vmi7dbQG+fxK3d3Y Oct 4 11:52:28 localhost sshd[252]: error: no more sessions Oct 4 11:52:28 localhost shepherd[1]: 1 connection still in use after sshd-2 termination. Oct 4 11:52:28 localhost shepherd[1]: Service sshd-2 has been disabled. Then deploy crashes with 'Channel opening failure'. Due to the number of SSH connections made by deploy and frequent occurence of this problem, I was not able to successfully deploy through many attempts. I found that removing the memoizing open-machine-ssh-session* in (gnu machine ssh) works around it and can happily deploy again. (that is, just use 'open-machine-ssh-session' instead)