daily Continuous Replication backup in XO

rizaemet 0

Hello,
Same problem here. Job start 2 seconds before scheduled time. And start again 2 seconds later exact scheduled time. First run finish successfully. Second run fail with this error: "the job (...) is already running"

XO 5.50.1 from source.

rizaemet 0

@karlisi said in daily Continuous Replication backup in XO:

... this is happening only on first schedule after each XO restart. Next schedules are working without issues.

Hello again,
My CR jobs are same. This is happening only first schedule after each XO restart as @karlisi said.

olivierlambert

@julien-f can we reproduce?

julien-f

I've setup some tests, we should know more in a couple of hours.

julien-f

Cannot reproduce.

karlisi

@julien-f What is needed from me to understand what's happening? Today restarted my xo after os updates.

julien-f

It would help if you could reproduce the issue with the official XOA, because we know the environment and how it was built.

Or give me a step by step process (with all the backup config) to reproduce the issue.

julien-f

Also, can you go into the directory of xo-server and show me the output of this command please:

> node -p '[require("./package").version, require("@xen-orchestra/cron/package").version]'

karlisi

@julien-f said in daily Continuous Replication backup in XO:

node -p '[require("./package").version, require("@xen-orchestra/cron/package").version]'

[ '5.50.1', '1.0.4' ]

The best (or worst), last night after XO restart all backups went without problems. Yesterday I upgraded Ubuntu kernel. And expanded XO disk, because initially it was set too small and there was almost no free space left.

karlisi

@julien-f I have no XOA. I installed XO on top of Ubuntu 18.04 using this script:
https://github.com/Jarli01/xenorchestra_installer
Upgrades are made using another script:
https://github.com/Jarli01/xenorchestra_updater
How to send config to You?

Danp

@karlisi said in daily Continuous Replication backup in XO:

Yesterday I upgraded Ubuntu kernel. And expanded XO disk, because initially it was set too small and there was almost no free space left.

Funny.... I did the exact same thing yesterday in order to upgrade to Ubuntu 19.10. Now my Delta backup job has exhibited this same behavior of running twice after restarting XO.

Danp

@julien-f said in daily Continuous Replication backup in XO:

It would help if you could reproduce the issue with the official XOA, because we know the environment and how it was built.

I've just replicated it on the latest release channel of XOA. Let me know if you want me to also test it on the stable channel or if you want to remote into the VM to examine the setup.

julien-f

@Danp Thank you, latest is fine, do you have by any chance a sure process to replicate the issue?

Danp

@julien-f said in daily Continuous Replication backup in XO:

a sure process to replicate the issue

I'm able to replicate it on demand in my environment. Not sure how to translate that into something that would fail elsewhere.

Here's what I did --

Export config from my XO (sources) VM
Import config into XOA
Edit my standard delta backup job to run at new time
Reboot XOA VM

Here's the screen clip of both jobs --

Here's the failed job's log --

{
  "data": {
    "mode": "delta",
    "reportWhen": "failure"
  },
  "id": "1571917200008",
  "jobId": "dfe75d18-94ac-4bd1-a1c7-fb2170e75154",
  "jobName": "Nightly",
  "message": "backup",
  "scheduleId": "cf8b562c-7b0e-46e6-9b53-f78e9c15156c",
  "start": 1571917200008,
  "status": "failure",
  "end": 1571917200031,
  "result": {
    "message": "the job (dfe75d18-94ac-4bd1-a1c7-fb2170e75154) is already running",
    "name": "Error",
    "stack": "Error: the job (dfe75d18-94ac-4bd1-a1c7-fb2170e75154) is already running\n    at /usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.js:272:14\n    at Generator.next (<anonymous>)\n    at asyncGeneratorStep (/usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:30:103)\n    at _next (/usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:32:194)\n    at /usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:32:364\n    at Promise._execute (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/debuggability.js:303:9)\n    at Promise._resolveFromExecutor (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:483:18)\n    at new Promise (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:79:10)\n    at /usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:32:97\n    at Jobs._runJob (/usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.js:245:60)\n    at /usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.js:352:17\n    at Generator.next (<anonymous>)\n    at asyncGeneratorStep (/usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:30:103)\n    at _next (/usr/local/lib/node_modules/xo-server/dist/xo-mixins/jobs/index.js:32:194)\n    at tryCatcher (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/util.js:16:23)\n    at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:512:31)\n    at Promise._settlePromise (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:569:18)\n    at Promise._settlePromise0 (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:614:10)\n    at Promise._settlePromises (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:693:18)\n    at Promise._fulfill (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:638:18)\n    at PromiseArray._resolve (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise_array.js:126:19)\n    at PromiseArray._promiseFulfilled (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise_array.js:144:14)\n    at Promise._settlePromise (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:574:26)\n    at Promise._settlePromise0 (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:614:10)\n    at Promise._settlePromises (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/promise.js:693:18)\n    at Async._drainQueue (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:133:16)\n    at Async._drainQueues (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:143:10)\n    at Immediate.Async.drainQueues (/usr/local/lib/node_modules/xo-server/node_modules/bluebird/js/release/async.js:17:14)\n    at runCallback (timers.js:810:20)\n    at tryOnImmediate (timers.js:768:5)\n    at processImmediate [as _immediateCallback] (timers.js:745:5)"
  }
}

julien-f

@Danp can you show me the full config of your job please?

Danp

@julien-f Here's a screenshot. Let me know if that isn't what you meant.

Screenshot_2019-10-24 Backup(2).png

julien-f

@Danp Perfect, thank you for your help

I think this may be an old issue that has become visible since https://github.com/vatesfr/xen-orchestra/issues/4497

julien-f created this issue in vatesfr/xen-orchestra

closed Report backup as failed or skipped if already running #4497

julien-f

@Danp Please open a support tunnel in the appliance having the issue, I would like to check the database directly:

xoa support tunnel

julien-f

I think I understand how the job can run twice.

What I still don't understand though is how the job can run so soon (14 seconds before) or even exactly one minute before scheduled…

julien-f

FYI: https://github.com/vatesfr/xen-orchestra/issues/4625

julien-f created this issue in vatesfr/xen-orchestra

daily Continuous Replication backup in XO

closed Report backup as failed or skipped if already running #4497

closed [cron] Dont run before schedule #4625