gave it another thought: I don't think beaker usually terminates containers after a connection is terminated

a normal beaker run uses multiple scp connections and I also think multiple ssh connections, all sequentially

well, it calls host.close explicitly and we usually don't do that

ah

ok that terminate it

it worked for you locally with vagrant?

yes

mhm

so now I'm testing with a condition on the hypervisor to skip it on docker, see if that works

kind of weird https://github.com/voxpupuli/beaker/actions/runs/4449290275/jobs/7813262694 doesn't show output

I wonder if it's buffering output

bleh, looks like net-scp also closes the connection if something fails

meh

tests were probably never executed on docker

very likely

though there is https://github.com/voxpupuli/beaker/blob/19b8ddaf426c073fa38c5bc1fb0e172c67ceb426/acceptance/lib/helpers/test_helper.rb#L1-L9 so it's not like it never caused problems before

interesting

Hmm.. is the case just with sshd as docker_cmd?

now testing with the released gem version

hmmm, I also wonder why rsync is broken on beaker-docker, which makes me wonder if SSH is even running at all on the container

I think it does successful ssh connections?

or SSH is not properly deamonized and only accepts a single connection?

mhm, I think even when you start it foreground it accepts multiple connections

rsync returned #<Rsync:Result0x00007fbc30739800 @raw="ssh: connect to host 172.17.0.2 port 1991: Connection refused\r\nrsync: connection unexpectedly closed (0 bytes received so far) [sender]\nrsync error: unexplained error (code 255) at io.c(235) [sender=3.1.3]\n", @exitcode=255>

mhm

Does it happen only on Ruby 3.2 with the latest changes?

no, I tested on Ruby 3.2

3.1*

the generated dockerfile doesn't look different compared to our usual module CI jobs

no, it's calling beaker-hostgenerator so that should be what we're used to