Day '0' out of range 1..30 at /usr/local/sbin/sanoid line 413

[ryanjaeb]

I'm setting up sanoid for the first time today, so it's possible I've configured something wrong, but I followed the CentOS instructions and sanoid.conf example almost exactly. It seems like this broke after UTC rolled over to June 1:

TZ=UTC date && TZ=UTC /usr/local/sbin/sanoid --take-snapshots --verbose

Sat Jun  1 04:20:53 UTC 2019
INFO: taking snapshots...
Day '0' out of range 1..30 at /usr/local/sbin/sanoid line 413.

With my local timezone (-600) which is still at May 31:

date && /usr/local/sbin/sanoid --take-snapshots --verbose

Fri May 31 22:22:48 CST 2019
INFO: taking snapshots...
taking snapshot neo/enc/images/testing@autosnap_2019-05-31_22:22:48_monthly
taking snapshot neo/enc/images/testing@autosnap_2019-05-31_22:22:48_daily
taking snapshot neo/enc/images/testing@autosnap_2019-05-31_22:22:48_hourly
taking snapshot neo/enc/images/testing@autosnap_2019-05-31_22:22:48_frequently
INFO: cache expired - updating from zfs list.

[normanu]

Same issue here and getting 100's of mails about it

[shodanshok]

I confirm the bug, which was indtroduced here: #362
Sorry for the inconvenience; I am thinking about a workaround, which I should publish later today.

[shodanshok]

Hi, here you can find the fast fix: shodanshok@9bb8f8e

The fix basically reverts to the method to calculate the previous day in the special case of the first day of month. Note that this can lead to some duplicate snapshot in the rare case of DST happening the first day of a month (which was the reason I authored the change in the fist place).

For manual patching, copy/save the code above and use the patch <your_sanoid_file> -i <this_patch_file> to apply.

412,413c412,417
<                                               $preferredtime[3] -= 1; # preferred time is later today - so look at yesterday's
<                                               $lastpreferred = timelocal(@preferredtime);
---
>                                               if ($preferredtime[3] > 1) {
>                                                       $preferredtime[3] -= 1; # preferred time is later today - so look at yesterday's
>                                                       $lastpreferred = timelocal(@preferredtime);
>                                               } else {
>                                                       $lastpreferred -= 60*60*24; # workaround for first day of month
>                                               }

[scotws]

Got this bug today, rollover to July 1st. I can assume I can just wait out the day with the crontab line for sanoid disabled until tomorrow?

[shodanshok]

@scotws Correct.

[normanu]

@shodanshok the error is still there now also on the 2nd?

[shodanshok]

@normanu On 2nd you should have no problems. Anyway, you can apply the fast fix shown here: shodanshok@9bb8f8e

Be sure to read the entire PR thread here: #395

[shodanshok]

@jimsalterjrs as this is quite an important bug to fix, can you look at #395 or #406 ?
Thanks.

[rwarren]

I've also just spontaneously run into this bug. I did nothing to trigger it... it just started happening 2.5 hrs ago on the day flip. See below for reproducing manually (normally on a cronjob):

$ sudo /usr/local/bin/sanoid
INFO: taking snapshots...
Day '0' out of range 1..31 at /usr/local/bin/sanoid line 413.
$ date
Thu Aug  1 02:36:26 UTC 2019

[rwarren]

The fix indicated by @shodanshok worked for me:
shodanshok@9bb8f8e

Thanks, @shodanshok !!