I’ve been able to get emailed errorlogs to come to me from my rocstor installation - I’ve received this when the scheduled snapshot runs:
Traceback (most recent call last):
File “/opt/rockstor/bin/st-snapshot”, line 45, in
sys.exit(scripts.scheduled_tasks.snapshot.main())
File “/opt/rockstor/src/rockstor/scripts/scheduled_tasks/snapshot.py”, line 95, in main
validate_snap_meta(meta)
File “/opt/rockstor/src/rockstor/scripts/scheduled_tasks/snapshot.py”, line 39, in validate_snap_meta
if meta[‘share’].isdigit():
AttributeError: ‘int’ object has no attribute ‘isdigit’
My weekly (friday) last run was May 17th 2019, 1:00:00 am - it had managed to get snapshots on 10th and 17th, but has failed for the last two weeks.
The schedule parameters are:
Task name: MEDIA_Weekly
Task type: snapshot
Share name: MEDIA
Snapshot prefix: MEDIA_SNAPSHOT_
Maximum count * 5
Make snapshots writable? No
Make snapshots visible? Yes
Enable task? yes
Task frequency Every week on Friday at 01:00
Logging into the server, and looking at the directory:
[root@rockstor_home ~]# cd /mnt2/MEDIA/
[root@rockstor_home MEDIA]# ls -al
total 0
drwxrwxr-x 1 carl carl 164 May 17 01:00 .
drwxr-xr-x 1 root root 364 May 17 12:57 …
drwxr-xr-x 1 root carl 430 May 11 20:17 Books
drwxr-xr-x 1 root carl 20 May 6 18:47 Christmas
drwxrwxr-x 1 carl carl 48 May 6 18:57 .MEDIA_SNAPSHOT__201905100100
drwxrwxr-x 1 carl carl 106 May 10 20:00 .MEDIA_SNAPSHOT__201905170100
drwxr-xr-x 1 root carl 1666 May 14 18:48 Music
drwxr-xr-x 1 root carl 212 May 12 19:23 VIDEO
Checking through rockstor.log and /var/log, I don’t see anything that is standing out…
Happy to do further checking…
Bit of background - I’m thinking of implementing rockstor in a church office, replacing my home-grown similar, but clunky non-web interface system - the stability / reliability of scheduled snapshots is the critical element that needs to work…
@carl We did have a breaking update quite a while ago with an update and it looked something like this. The ‘work around’ was to delete the scheduled snapshot task and re-create it. It was unfortunate and we had to make some pretty deep changes on a design level that made some breakage difficult to avoid.
Git that a go and do mention if this did not coincide with an update as that would make it more likely to be an as yet unknow bug. But we haven’t had any reports of this that can’t be explained by an update (at least yet).
Hope that helps.
Incidentally the low level move we made was to transition our share / pools over from name to number and hence the breakage in scheduled snapshot tasks that previously referenced name and then expected a number.
This looks to be related, although strangely the other way around. Try deleting the scheduled task and re-creating and report back on your findings.
Linking to your prior scheduled (scrub in this case) task which is the only other recent report of scheduled tasks issues. I’m guessing these tasks were both created in an earlier version of Rockstor and both suffered from this API change we had to make. Bit of a rocky time it was but we had to do it as many other problems were sorted by that change but unfortunately we failed to catch all of them in their scheduled tasks knock on.
Hope that helps and thanks for helping to support Rockstor’s development via a Stable channel subscription.
Ok - many thanks - I’ll give that a go - as a matter of interest, where is the Task Definition data stored? I tried to trace through the code to see if I could get any insight, but its fairly complex (I tend to keep to KISS principle hence my mention that my version of this type of thing was clunky (all done in simple BASH scripting to create snapshots on a CRON task…
Cheers
hence my mention that my version of this type of thing was clunky (all done in simple BASH scripting to create snapshots on a CRON task… 