Manual vs Scheduled

[zim2323]

We are using a trial of SuperFlexible Pro v5.35e to pull data from an SFTP server. The profile is created so that the source is checked every hour and anything found is MOVED to the destination (one way). When I run the profile manually everything works as expected.

However, when the profile is run according to schedule (installed service), we get this error:
SSH error 114.
Timezone: listing offset 30, timestamp setting offset -30
I have the profile set to retry 5 times, and after the 5th try it stops as failed.

Now, doing research and searching your forums, I found that I could disable "Auto timezone" checking in the SFTP Advanced config. I also found that the SFTP server was 36 minutes off from the destination server, which explains the error. I disabled Auto and set the offset to 60/-60. Now everything works as expected.

My question is, what is different between a manual run and a scheduled run??? WHY is anything different? Why does a manual run not care about the timezone/difference, but the task run as scheduled does?

I'm confused, please explain!

Thanks!

[superflexible]

The timezone offset is calculated only once per day, or anytime after you edit the profile. For a deeper analysis, I would have to compare two log files (one attended, one unattended).

The timezone offset is not an error, just something that the program found out.

SSH Error 114 is more interesting. That is a login/authentication failure. Maybe the timezone check caused that for some reason, but I don't know that right now.

[zim2323]

Either way, whether run manually or through the service, the profile should be run the exact same way, shouldn't it?

The logs for the manual run are clean. And the authentication error only showed up when run as a service. As soon as the timezone settings were changed, then that cleared out of the logs.

[superflexible]

Either way, whether run manually or through the service, the profile should be run the exact same way, shouldn't it?

Yes, most of the processing is identical when run in background mode via the service. But it's probably running under a different user account. And there are other subtle differences. Such as running in a sub-thread of the service rather than the main thread of the GUI process. There are also lots of differences related to user interaction, such as allowing deletions and so forth. A background job also needs less memory because it keeps a smaller list of files in memory (it doesn't have to be ready for a user clicking on "Show All" in the Sync Preview window).

So there are actually a lot of differences, but the job should in principle be able to do the same thing. But in rare cases like this, you may see an error in one mode and not in the other. If you have found a solution, we don't have to look into it.

[zim2323]

Great explanation! Thanks for your time! That makes a lot more sense. Really loving the flexibility of your products!