[jlinkels]

Hello Orsiris,

I have found one typo in /dev/tests/sudo_prep.sh. The patch is in this PR.

A question about run_tests.sh. Is it actually current and functional? I am not complaining, but if it should be functional, I am doing something wrong. However if the status is unknown it might be there are errors in the code.

For one, when executed as osyncsudo, this line:
SUDO_EXEC=yes osync.sh --initiator=/home/osyncsudo --target=ssh://osyncsudo@localhost:22//root/osync-tests --rsakey=/home/osyncsudo/.ssh/id_rsa_local
fails with the error:
Remote replica path [/root/osync-tests/] does not exist / is not writable.
Which is a bit surprising because I assumed osyncsudo would execute this using sudo.

When I create a directory /tmp/osync-tests, the tests run successfully but osync cannot clean up some folders it created during the tests, like osync.remote.428385.20261026T122541.11521 which are owned my root, not by osyncsudo.

Then another question, not related to tests:
I use osync in a single target - multiple initiator setup. That is, I have some files on a server accessible from the public internet. And I have a number of clients which must sync this directory. It can happen that I work on alternate clients with short intervals in between. It is nice to have the target-helper functionality so the server signals the clients that a sync action has to be run.

However, in the process of planting the osync-update.push this fails when the client is off-line. Either when pinging the target in advance, or when executing the SSH command in _TriggerInitiatorRunRemote. This results in a error, mails being sent, etc.

I do not consider it an error when the client is off-line. Clients can be sleeping, laptops disconnected etc. It is a normal condition when a client can not be reached from the server. It would be nice however if normal operation is resumed after the client comes on-line again. I do not mean that the target must defer the push notification to the initiator and execute the notification as soon as the initiator comes back on-line. First that is too complicated, secondly the initiator can easily trigger its own sync action when coming back on-line. On the target I want to avoid error logs filling up or my mailbox filling up with error messages which are not errors.

So I made a change to _TriggerInitiatorRunRemote to call CheckConnectivityRemoteHost. If this check fails, no errors are written and _TriggerInitiatorRunRemote returns no error. This happens only when these conditions are met:

• osync is in target-helper mode
• the target is on a remote host
• a (new) flag: REMOTE_PING_SILENT_FAIL=true

In addition, I pass this flag also to ExecTasks when called from CheckConnectivityRemoteHost to mute error logging. ExecTask has a parameter #13 noErrorLogsAtAll which allows that.

If this all is not clear I am happy to create a draft pull request for you to review. (I never did that, creating a draft PR so please bear with me)

But then again, is this elegant what I do? When I read thru the issues and commits, osync was created to run on the initiator and the target was just sitting there. Then you added the target-helper mode to trigger a sync action. Now I want to add a mode that no error occurs in target-helper mode when the initiator is off-line. It seems I try to use osync for a purpose it was not intended for.

See, all the target needs is to wait for a change to happen, and write a file into the initiator. All it needs is the IP address of the initiator and the location on the initiator where to write the notification. There is little which can go wrong, there cannot be any conflicts or deletions, no state recordings needed. I see it more like a UDP packet sent to a client, when it arrives it is fine, if it doesn't, it might arrive on the next try. This doesn't need a 6000-line script, it can be done in 10 lines including comment. If something is wrong in the configuration on the target, starting the script will tell. Syncing, logging and reporting will be performed on the initiator anyway. And that robustness, resilience, error checking and reporting on the initiator is fully justified.

So I don't feel quite confident if I really should modify osync for this purpose. Or better create my own, very simple notify script on the target.

What do you think?

Cheers,
Johannes