As part of our FinalBuilder script we run some SSH Execute actions that can take a significant time to complete (10-60 minutes). The timeout for those actions is -1, which the dialog documents as “wait until the command completes”. Our existing build machine has FinalBuilder 8.0.0.3364 and the scripts are waiting successfully. I just set up our new machine with FinalBuilder 8.5.0.3497 and even though the scripts are identical it’s now failing with a “Response reading timed out” error with a “Run time” of 00:00:00:073. Other SSH Execute actions with timeouts > 0 are working correctly. Since the dialog caption hasn’t changed, I assume this change of behavior was unintentional.
In case it’s relevant, the old build VM was Windows 10, the new one is Windows 11 24H2, and they’re connecting to a Mac Mini on the same ethernet switch.
It turns our we misread the ssh client library documentation. It has 2 timeout properties, the connection timeout supports 0 or -1 for infinite wait - the command timeout does not.
I have changed the code so that if the command timeout is 0 or -1 then we set the actual command timeout to 24hrs.
This build has the fix - it also includes an updated ssh client library which has several compatibility improvements.
@Vincent I’m seeing some sort of regression around this again.
I’m currently using FinalBuilder 8.6.0.3656 and an SSH Execute Command action is returning:
Response reading timed out..
Exit Code [999].
The first line is in red, the second in white (in dark mode). The action previously had a Command timeout (ms) of 5400000 (90 minutes), but I’ve also tried -1. The action itself only has a Run Time of 00:01:40:125. The action also isn’t marked as failing in this case, so the script continues running the rest of the commands.
I’m seeing the same failure connecting to both a Linux system and a macOS on. It seems to have started failing sometime since yesterday morning, though I can’t find anything that would have changed in that time. I had been previously running 8.6.0.3648 from the WinARM64EC thread, and upgrading to the stable release didn’t help. Restarting the remote systems also didn’t help.
The VM FinalBuilder is running on is on Windows Server 2025 Standard 24h2, 26100.33158. Check for Updates shows it’s up to date, and the only things that were applied in the last week were a couple of Windows Defender “Security Intelligence Update for Microsoft Defender Antivirus - Current Channel (Broad)”. Our sysadmin said he wasn’t aware of any updates for either macOS or RedHat that would have affected things.
I’m happy to provide any additional information or testing you need, but I haven’t had any luck finding anything whatsoever that would have changed to break this.
Thanks, Vincent. Apologies for the confusion earlier, I’ve been sick and I forgot that I upgraded from 3648 to 3656 on Monday (and now 3666) so that would have been when things broke.
I did run into another difference in behavior compared to the previous SSH library: Running multiple SSH Execute Command actions in a row no longer maintains the working directory from one command to the other and instead defaults to the user’s home directory, so if you do a cd <dirname> in one action and then call a script relative to that directory as a second action, it fails.
Thankfully we do the vast majority of the work in that script rather than a chain of FB actions, so I can work around the change with relatively little effort, but I could see it being much more disruptive for others.
Ok, figured it out - the terminal session was being closed after each command execution - which resulted in a new terminal session with the working directory reset.
I have tested it here but I cannot guarantee there won’t be futher issues. We do not have the source to the library (it’s a dotnet library) which makes debugging it more difficult.
Thanks, I appreciate the quick turnaround, and no worries about the transition pains, I totally understand. We use SecureBlackBox ourselves, with a fair few patches, and our own transition off it has been repeatedly delayed due to the complexity of reimplementing everything.
Yeah we were using an old version of SecureBlackBox - we had paid for a lifetime license, but when n/software bought them out, they reneged on that and also no longer provided the source code. We did update once but their support was terrible.
We’re using Rebex now since we also use that in our dotnet based products, but my preference would be native delphi - we’re using devart securebridge for sftp - we’ll probably switch to that for ssh on v9.