Hi,
I'm getting many warnings about event ID 0 in Event Viewer when I run rclone to sync with my Azure cloud. The description for Event ID 0 from source E:\rclone\rclone.exe cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
Example command that I use: E:\rclone\rclone.exe sync documents: azureblob:documents -v --fast-list
where azureblob is of type "azureblob" and documents is just alias for local folder
I'm using:
rclone v1.45
os/arch: windows/amd64
go version: go1.11
Can you check the timing of this a bit more specifically and see if it happens when the rclone process stops specifically?
Because what this intuitively looks like most to me is is just exiting with standard exitcode 0 to indicate a normal exit, and that is somehow being picked up in event viewer - but even viewer can't dig up any spesific information on this exit code and thus throws a warning.
Keep in mind that rclone was primarily developed on Linux, so I wouldn't be surprised if spesific support for this type of event-monitoring in Windows is lacking.
If this is the case then it would be a warning you could just ignore - or mute if that is possible.
I can't see this replicated in my own logs though (assuming it's under application).
Can you elaborate on how you installed rclone?
The thing that is throwing me off the most here is why eventviewer would be picking up this event in the first place... maybe that registers automatically if you run it via task-scheduler or as a service...
events can be created in so many ways.
any application including the operating system can generate event code 0 for all kinds of reason.
tho i am not an expert, i think event code 0 it is a catchall kind of thing of corrupted or missing files or registry entries.
I'm using a log file, I've just ommited it from the example command
I've downloaded the latest version now and get the same warnings
the messages are in the Application log (Windows logs -> Application)
changing the path / alias has no effect. Even a simple command such as "rclone lsd azureblob:" produces it
The timing is for each file uploaded, or for big files multiple events (for each chunk uploaded I think)
Have you tried it with Azure blob? It seems to be the culprit.
I have not really "installed" rclone so much as just extracted it into a folder.
Normally I do run a .bat file with rclone command from a scheduled task, but I get the same warning from doing it manually from Command Prompt.
Ok so now I've tried syncing a few files on my local FS to another folder on my FS and there is no events generated for this. But if I try an azureblob command (for example i tried rclone lsd azureblob:) I get a warning event in the log. I should also note that this happens on another computer as well (using a different azure blob repository).
i use azureblob and have no such messages in the event log
have you run rclone with the flag -vv instead of -v yet?
in the rclone log, are there any warnings or errors?
are there any errors or warnings in the rclone log that occurs at the same time as the message in the event log?
you mentioned that you get the same event log entry on two computers.
are you using the same exact config file on both computers?
if so, in the config file, delete the entry for azure and re-create the entry and test again.
create a .cmd batch file and add this command before the command for run rclone.exe.
or from the command prompt, run this command and then run rclone.exe
I agree that we should take a look at debug output from rclone before we escalate this.
use either
-vv
or
--log-level DEBUG
to enable debug-level logging These get large real quick, so try to keep them limited to reproducing the problem as succinctly as possible. If even a simple command reproduces it then by all means use one of those. The less complicated we make the test-log the easier it is to narrow down the cause.
Hopefully the error in the event log is mirrored in some kind of error in rclone with more detail.
I have run the sync with -vv and it doesn't produce any useful info:
2019/10/19 18:55:17 DEBUG : rclone: Version "v1.49.5" starting with parameters ["E:\rclone\rclone.exe" "sync" "SampleFiles:" "azureblob:test" "-vv" "--fast-list" "--log-file" "E:\test\log.txt"]
2019/10/19 18:55:17 DEBUG : Using config file from "C:\Users\Peter\.config\rclone\rclone.conf"
2019/10/19 18:55:17 DEBUG : test1.txt: Sizes differ (src 22969005 vs dst 22969002)
2019/10/19 18:55:17 INFO : Azure container test: Waiting for checks to finish
***snipped log of other test files that were unchanged
2019/10/19 18:55:17 INFO : Azure container test: Waiting for transfers to finish
2019/10/19 18:55:27 DEBUG : test1.txt: MD5 = 0d37ac7eb6b849dee1d76acfedd5c5f0 OK
2019/10/19 18:55:27 INFO : test1.txt: Copied (replaced existing)
2019/10/19 18:55:27 INFO : Waiting for deletions to finish
2019/10/19 18:55:27 INFO :
Transferred: 21.905M / 21.905 MBytes, 100%, 2.128 MBytes/s, ETA 0s
Errors: 0
Checks: 6 / 6, 100%
Transferred: 1 / 1, 100%
Elapsed time: 10.2s
2019/10/19 18:55:27 DEBUG : 11 go routines active
2019/10/19 18:55:27 DEBUG : rclone: Version "v1.49.5" finishing with parameters ["E:\rclone\rclone.exe" "sync" "SampleFiles:" "azureblob:test" "-vv" "--fast-list" "--log-file" "E:\test\log.txt"]
I've also tried putting set GODEBUG=http2client=0 on the first line of the .bat file that executes the snyc command and I haven't noticed any difference in output.
The second machine has a different config and also a different Azure account. Both using cold tier blob storage.
Recreating the entry for azure storage blob made no difference.
I've now noticed the warning log only shows up for operations that take more than 3 seconds.
Notice the "Slow >3s" keyword:
==> REQUEST/RESPONSE (Try=1/3.6730596s[SLOW >3s], OpTime=3.6730596s) -- RESPONSE SUCCESSFULLY RECEIVED
When I was testing with small files there was no events logged.
Also all subsequent lsd commands produced no event, since they finished faster than the first one, which took ~10 seconds and produced another [SLOW >3s] response in event log.
When we don't see any obvious errors in the logs it's probably time to call in the boss for a comment.
Otherwise we risk a long and arduous wild-goose-chase before we stumble upon the trigger...
@ncw any ideas on how we can proceed with troubleshooting on this?
I would be willing to try to replicate your issue on my Windows10 setup with as-close-to-your-config as possible, but I don't have any Azure access.
So unless you trust me blindly to not mess with your data that would require you set up a temporary authorization that you can revoke later + a safe isolated testing area. If you are willing to go through that trouble I am willing to test it for you. You decide It would no doubt be helpful information in rooting out the problem though.
I suspect it's not really a big problem all-in-all as long as you can verify your files do arrive whole and safe. That said, I hate leaving problems half-solved...
I've ran the check and all files match with 0 differences found
If you're willing to test it I can give you access to a test storage. I'll set it up tomorrow and PM you the details. In the meantime @ncw might also shine some of his wisdom on this thing
Can confirm that this beta version is not showing any event in the event log.
Thank you
One thing I noticed though: with the non-beta version when I accidentally tried syncing to root of the test azure container I got an actual Error level event in the event viewer, the beta version on the other hand hides all these events (Error and Warning level events). So if there's a way to let only Error level events through, someone might find them useful.
These events would only work for azure blob storage so I think the events are better off here and if we really want windows events then it should tie into rclone's logging system so all rclone events of a certain severity could become windows logs!
I've merged this fix to master now which means it will be in the latest beta in 15-30 mins and released in v1.50
It would no doubt be helpful information in rooting out the problem though.