Strace alternative on Windows is call process explorer.
https://www.google.com/url?q=https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer&sa=U&ved=2ahUKEwj2gv7YjIT0AhXFZd8KHdGfDCIQFnoECAAQAg&usg=AOvVaw1-3_h7g_9CdhMo912PswMC
On Fri., Nov. 5, 2021, 12:48 p.m. EricZolf, <ewl+rdiffbac...@lavar.de>
wrote:
> Hi,
>
> that's really a tricky one without any error message, so poking in the
> dark:
>
> 1. do you.see rdiff-backup in the list of processes?
> 2. if the rdiffbackup.bat content is simpler, what happens?
> a. just `rdiff-backup.exe -v`
> b. C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 9 --remote-schema
> >>> "C:\Windows\System32\OpenSSH\ssh.exe %%s rdiff-backup --server"
> >>> r...@datasrv2.intra.hoec::%BACKUPTO%
> c. C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 9
> r...@datasrv2.intra.hoec::%BACKUPTO%
> 3. On Linux, I would call strace on the rdiff-backup process, and guess
> where it's stuck. Anything similar under Windows?
>
> KR, Eric
>
> On 5 November 2021 15:10:57 UTC, Michael Crider - HOEC <
> mcri...@hoecoop.org> wrote:
> >I sent this privately to Eric by mistake, now replying on list.
> >
> >Hi Eric,
> >
> >Answers inline below.
> >
> >On 11/1/21 1:22 PM, Eric L. Zolf wrote:
> >> Hi Michael,
> >>
> >> it's difficult to tell without a more concrete error message. Running
> >> the command in debug mode (-v 9) might help to understand where the
> >> script hangs.
> >Running the command with -v 9 didn't change anything. The program still
> >crashes after making an ssh connection to the backup server with no
> >visual output, but doesn't return to the command prompt.
> >> What happens if you call `ssh ${BACKUP_USER}@${TARGETHOST}
> >> rdiff-backup.bat ${BACKUPTO}` like the cron job?
> >Same effect.
> >> Or even something like
> >> `ssh ${BACKUP_USER}@${TARGETHOST} C:\Windows\System32\OpenSSH\ssh.exe
> >> r...@datasrv2.intra.hoec rdiff-backup --server`
> >This runs successfully, starting "rdiff-backup --server" on the backup
> >server and closing when I kill the process on the backup server.
> >> But as you said that the issue appeared after an update of Windows, I
> >> can currently only imagine that something changed with SSH. I would look
> >> if perhaps something changed in the SSHD _and_ SSH configuration files
> >> between 1909 and 21H1, something which makes a difference between
> >> connecting interactively or not.
> >Unfortunately we have already upgraded all our Windows computers to
> >21H1, so I don't have configuration files from 1909 to compare. For now
> >I have worked around the problem by writing an expect script, run from
> >the cron job on the backup server, that spawns an ssh connection and
> >executes the batch file. This completes and exits successfully.
> >> On 01/11/2021 16:21, Michael Crider - HOEC wrote:
> >>> We have used rdiff-backup for well over 10 years for our Linux servers
> >>> and workstations, and until recently to back up Windows servers and
> >>> workstations we mounted their drives locally on the backup server and
> >>> ran rdiff-backup against the mount. When our first Windows 10
> >>> workstations arrived with v1909, we started having trouble reliably
> >>> mounting the drives, so we recently put the Windows executable of 2.0.5
> >>> on our Windows workstations and tried the same method we use for Linux
> -
> >>> a cron job on the backup server would ssh to the Windows workstation
> >>> (running the built-in OpenSSH server) and call a batch file that would
> >>> run rdiff-backup, sending the backup back to the server. Keys were in
> >>> place to allow passwordless connections. This way we could schedule
> >>> several workstations to run in sequence without having multiples
> overlap
> >>> in time (as might happen if we did the scheduling at the workstation).
> >>> That was very stable on workstations running Windows 10 1909 and below.
> >>> Then we upgraded all of our workstations to 21H1. Now we can manually
> >>> ssh to the Windows workstation and run the batch file and it runs just
> >>> fine. But if we run the cron job script that does the ssh and runs the
> >>> batch file, everything works (setting environment variables and
> updating
> >>> specific local files from network masters using scp) until the
> >>> rdiff-backup command. We don't have "echo off" on the batch file so we
> >>> can see the command issued. It makes the connection to the backup
> server
> >>> and starts rdiff-backup on it, but then it hangs and doesn't progress
> >>> any further, and no files are updated in the backup destination. We
> >>> started with rdiff-backup 2.05 using SysNative in the remote-schema,
> >>> then moved to 2.1.0a1-64 to see if that helped (changing the
> >>> remote-schema to System32 but leaving everything else the same). but
> >>> nothing changed except for an added warning about the server not
> >>> understanding the API. If we are running the cron script in a terminal
> >>> we can press Ctrl-C and exit. If it runs from a cron schedule we have
> to
> >>> kill rdiff-backup on either the workstation or the server. Has anyone
> >>> else seen something similar?
> >>>
> >>> The command in the cron job is: ssh ${BACKUP_USER}@${TARGETHOST}
> >>> rdiff-backup.bat ${BACKUPTO}; RDIFF_RESULT=$?
> >>>
> >>> The command in the batch file is:
> >>> C:\rdiff-backup-2.1.0a1-64\rdiff-backup.exe -v 6
> >>> --exclude-symbolic-links --remote-schema
> >>> "C:\Windows\System32\OpenSSH\ssh.exe %%s rdiff-backup --server"
> >>> --include "C:/FuturaData" --include "C:/Program Files (x86)/Futura
> >>> Systems/FuturaGIS/Staking Client" --exclude
> >>> "C:/Users/%BACKUP_USER%/AppData/Local/Temp" --exclude
> >>> "C:/Users/%BACKUP_USER%/AppData/Local/ESRI/Local Caches" --include
> >>> "C:/Users/%BACKUP_USER%" --exclude "C:/**" C:/
> >>> r...@datasrv2.intra.hoec::%BACKUPTO%
> >>>
> >>> Both use environment variables set on the command line of the script or
> >>> earlier in the script.
> >
>
>
