Timeouts on uploading files, with high CPU usage

[ianbrody]

Sometimes grive times out when uploading a recently changed file, after using 100% of the cpu for about 5 minutes. Here's a bit of the output messages:

sync "<file I just changed>" changed in local. uploading
HTTP PUT "https://www.googleapis.com/upload/drive/v2/files/<identifier>?uploadType=multipart&newRevision=false"
HTTP response 408
Error syncing "<file I just changed>": HTTP 408

I also captured a full log (with --log-http) but it's long and I'm not sure I've sufficiently redacted the personal information, so if it would help to look at it, is there somewhere non-public I can send it?

This doesn't happen every time, but I can semi-reliably trigger this bug by just changing this file a bit (it's a pdf) and then re-running grive soon after a previous run. I've also seen it happen to other files.

[juacq97]

Same issue here, and if you have the auto-sync the pc use the 100% of CPU all the time

~/Drive 
 $ grive
Reading local directories
Reading remote server file list
Synchronizing files
sync "./sync/documento-git/documento.org" changed in local. uploading
Error syncing "./sync/documento-git/documento.org": HTTP 408
Finished!

[Crandel]

I have the same issue always, then changes should be uploaded to drive. Need to use rclone for this

[novazur972]

Recently, I too have this same 408 error, on files that have been synchronizing without problems for years (but no problem of CPU usage, just a very long timeout). I don't understand what it is, and especially not how to correct the problem. It's very penalizing and it completely breaks the automation of backups if every day has to be done manually.

$ time /usr/bin/grive -p ~/gdrive/ 
Reading local directories
Reading remote server file list
Synchronizing files
sync "/foo/bar.pdf" doesn't exist in server, uploading
Error syncing "/foo/bar.pdf": HTTP 408
Finished!

real    9m52,602s
user    0m9,578s
sys     0m2,671s