Repository navigation
stdinserver is not restarted after timeout? #77
Description
hi,
first, thanks for zrepl, it is awesome.
i have this problem:
did my setup after the tutorial, tested manual ssh from backup-srv if stdinserver is responding, closed the ssh session with ctrl+c.
afterwards zrepl on app-srv shows this:
SSHCON_PROXY_ERROR2018/06/19 11:17:46 error: dial unix /var/run/zrepl/stdinserver/isenu-backup1: connect: no such file or directory
and i think it never recovers. maybe the stdinserver could be supervised? maybe i did something wrong.
thanks!
Activity
problame commentedon Jun 19, 2018
However, zrepl daemon must be running on both sides.
zrepl daemon does not create the /var/run/zrepl/stdinserver directory.
On FreeBSD, this should be handled by the
/usr/local/etc/rc.d/zrepl, see https://svnweb.freebsd.org/ports/head/sysutils/zrepl/files/zrepl.in?view=markup#l57Are you running the daemon with the rc script or manually from the command line?
If so, maybe try running it from rc script once so the
installcommands get run and create the runtime dirs.shivno commentedon Jun 19, 2018
on freebsd, 0.3 with the rc script, right, runs on both sides. everything works ok, can you reproduce this?
problame commentedon Jun 19, 2018
Uh, so if I understand you correctly, it works if you don't do the ssh test-connect?
shivno commentedon Jun 19, 2018
right, i guess go closes the socket if it is being exited uncleanly or so. probably is reproducible locally somehow by starting zrepl stdinserver backupservername, then just kill the shell or similar.
problame commentedon Jun 19, 2018
I think it's a combination of https://github.com/problame/go-netssh/blob/master/serve.go#L114 and https://github.com/zrepl/zrepl/blob/0.0.3/cmd/config_job_source.go#L159
However, I think the zrepl source side should log https://github.com/zrepl/zrepl/blob/0.0.3/cmd/config_job_source.go#L170 in that case
shivno commentedon Jun 19, 2018
right, it logs that. but the socket should stay alive imho, otherwise no further backups can be transferred. i dont know go so i dont know what is wrong.
problame commentedon Jun 19, 2018
Right, so I guess we're lucky that if users follow the tutorial 1:1, they won't run into this (because the zrepl daemon is not yet running on the other side)
Will find a fix for 0.0.4. Thanks for reporting, patches are always welcome ;)
shivno commentedon Jul 4, 2018
this is actually a severe issue, i just discovered that backups werent transferred for 2 days because of this issue (no logcheck yet on that server). so an addition to the docs exclaimer would be good imho with reference to this ticket or something. otherwise it works great!
job source: do not stop listener on accept() errors