Scheduled Scrub not running

[phillxnet (Philip Guyton)]

@magicalyak it would appear from your logs:

@magicalyak

[21/Aug/2017 10:02:02] ERROR [scripts.scheduled_tasks.pool_scrub:76] Failed to start scrub at pools/bigdata/scrub
[21/Aug/2017 10:02:02] ERROR [scripts.scheduled_tasks.pool_scrub:37] Failed to get scrub status at pools/bigdata/scrub/status
[21/Aug/2017 10:02:02] DEBUG [scripts.scheduled_tasks.pool_scrub:87] task(5) finished with state(error).

That you have not re-created your scrub tasks post 3.9.1-2 release (see later) ie from my first comment in this thread here and my first too yourself in this thread :

@phillxnet

@magicalyak Hello again:

magicalyak:

I’ll see if it’s the same issue but it’s scrubs not starting.

Cheers that would be good.

Just try re-creating those tasks as then they adopt the new pool API, assuming you have all the recent testing channel updates in place of course.

ie the url for your logged tasks is using the pool name where as from the end of the last testing release (last stable) and all throughout the current testing channel release cycle we have been using the db id of a pool not it’s name in the API calls. And more specifically the second testing channel update released in the current testing channel, 3.9.1-2:

Dev log for 3.9.2

Happy Saturday! 3.9.1-2 is now available! Thanks to @phillxnet for closing two issues for this update. One is a bugfix in scrub scheduling and the other is an enhancement in disk management. Enjoy the update!

ie:

scripts.scheduled_tasks.pool_scrub - update_state constructs url=pools/2/scrub/status

and then uses that to query the scrub state.

Sorry I should have double checked that you were on a relevant release and I obviously made a misleading mistake in my post:

@phillxnet

@magicalyak Thanks for trialing the delete re-add route, and given your cron entry (cheers) you now have the new pool API format (id rather and name) so could you please post the output of the following:

Silly me.

I was thinking that the number indicated the pool but of course as per my post to @peter:

@phillxnet

in the following db table which holds the current task status (largest id) and history:

psql -U rocky smartdb

pass as before

select * from smart_manager_task;

and the task_dev_id field there point to the contents of the following table:

select * from smart_manager_taskdefinition;

ie the figures in task_def_id column of the task table indicate the id entries of the taskdefinition table.

So for my example here:

cat /etc/cron.d/rockstortab 

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# These entries are auto generated by Rockstor. Do not edit.
*/5 * * * * root /opt/rockstor-dev//bin/st-pool-scrub 7 \*-*-*-*-*-*

that “7” points to:

psql -U rocky smartdb

select * from smart_manager_taskdefinition;
 id |         name         | task_type |                    json_meta                    | enabled |   crontab   | crontabwindow 
----+----------------------+-----------+-------------------------------------------------+---------+-------------+---------------
  7 | luks-on-bcache-scrub | scrub     | {"pool_name": "pool-on-luks-dev", "pool": "2"}  | t       | */5 * * * * | *-*-*-*-*-*
  6 | root-scrub3          | scrub     | {"pool_name": "rockstor_rockstor", "pool": "1"} | f       | */5 * * * * | *-*-*-*-*-*
(2 rows)

Oh well, my mistake; see how you get on after updating to the latest testing release and then deleting and re-creating your scheduled scrubs.

On my side of the updates wagon we now have the following pending pull request awaiting review:

scheduled scrub blocked by halted, conn-reset, and cancelled states. Fixes #1800

Thanks @magicalyak and I hope the above has sufficiently explained my misunderstanding.