11:19:26 If this yields undesired behavior (poor response, painting 11:19:26 Wireframing: -wireframe mode is in effect for window moves. 11:19:26 To disable this behavior use: '-noxcomposite' 11:19:26 X COMPOSITE available on display, using it for window polling. 11:19:26 supply the x11vnc '-noxdamage' command line option. 11:19:26 cause X DAMAGE to fail, and so you may not see any screen 11:19:26 Most compositing window managers like 'compiz' or 'beryl' 11:19:26 To disable this behavior use: '-noxdamage' 11:19:26 X DAMAGE available on display, using it for polling hints. I restarted the container and here is a log from where it started back up.maybe it has some useful info I've looked through everything and it all seems good but in Unraid when you go to the WebUI and login it says "Unable to connect to destination for 10 days". I set up the 2 way authentication for the web login but something else must be messed up. Mine has been working great for months but sometime in March it stopped connecting. sending all processes the KILL signal and exiting. crashplan-pro.sh: setting CrashPlan Engine maximum memory to 8192M 00-clean-logmonitor-states.sh: exited 0. 00-clean-logmonitor-states.sh: executing. executing container initialization scripts. ensuring user provided files have correct perms.exited 0. making user provided files available at /var/run/s6/etc.exited 0. I am not super technical however I looked into the setting and don't see anything abnormal.
#Unable to connect to backup engine crashplan update
It also states there is an update available, will go through the process until "done" but still keeps saying there is an update. Long time user.Īll of the sudden it will not stay started. I guess I've just never noticed the CPU usage before in the 4 or so years of using CrashPlan + CA Backups CPU utilisation has returned to normal now that it's finished uploading it (and it didn't take 3 days, either). I heard that maybe not enough RAM allocation can spike CPU so I added the env var for 4096M (as well as via the Crashplan command line), but it still seems to be hitting my CPU harder than I've seen before (while also only using 1.5GB RAM).Īny idea why? Is it common for large single-files to cause this and I've just never noticed before, or is something problematic going on?įYI: I think it was just related to that one large file. This isn't the first time that that file is backed up, but I've never noticed such a spike in CPU usage? Any ideas what could be up? It's currently backing up my ~26GB CA Backups file (which it reckons will take 3 days.).
Noticed that my CPUI was getting hammered this evening, and it looks like CrashPlan is the culprit.
0 kommentar(er)
