Stats not rolling over on MonthRotate

[graham8]

I installed vnstat 10 days ago and set MonthRotate to 28. Today, (30 Jan) it is still adding to January's total and hasn't started reporting February. I was expecting the monthly total to be reset at 00:00 28 January.

If it's relevant, 'Estimated' for January is showing 17x10^9 TiB.

[vergoh]

MonthRotate essentially defines the day when the previous month ends. 0:00 on that day becomes the beginning of the month currently reported by the system clock, that's why the default value of 1 results in regular calendar months to be followed. Because you changed the setting after the previous value had already taken effect (December->January), the change will not trigger on the 28th of the same month again. In your case, you have to wait for 28th February for the current "January" to end and February to begin.

[graham8]

Strange. So the condition for a reset of the monthly totaller is
Day==MonthRotate && DaysSinceMonthRotateChanged>30

[vergoh]

src/ifinfo.c (https://github.com/vergoh/vnstat/blob/master/src/ifinfo.c) starting from line 438 has the following condition:
if ((d->tm_mon!=month) && (day>=cfg.monthrotate)) {

d->tm_mon is the currently ongoing month from database point of view, month and day are from the current system clock and cfg.monthrotate is the value given for MonthRotate in the configuration file.

[graham8]

I see the problem. So something like
if (((d->tm_mon<month) || (d->tm_mon==month && cfg.monthrotate>15)) && (day>=cfg.monthrotate))
would do what I was expecting? That is:
a) not count for more than 30 days in the first month,
b) not call it January when most of the days are in February, and
c) correctly roll over in February when monthrotate==28

[vergoh]

I don't think that change would work as expected. The original comparison is done against the system clock and the month stored in the database when the month previously changed. In order to get February displayed during January, some sort of offset would need to be introduced to the handling of that timestamp or system clock every time the current month is compared, which just isn't there currently.

Most likely that sort of change would require modifications in more than just that single location. See for example the function rotatemonths() in dbaccess.c (https://github.com/vergoh/vnstat/blob/master/src/dbaccess.c) starting from line 524. It's one of the functions setting data.month[0].month which the ends up providing the d->tm_mon used in the comparison mentioned above.

[graham8]

Thanks for looking into it. If I have an idle moment I might have a closer look at the code. Meanwhile, I reset monthrotate to 1 yesterday so at least I am now on February. I realise that means if I change monthrotate back to 28 it won't rollover until 28 March.

There may also be a problem with running on devices without a RTC if vnstat updates before a the system clock is syncronised. Or have you covered that?

[vergoh]

The daemon has a sanity check for the system time compared to the last known database update. In can be found from the datalist_timevalidation() function in src/daemon.c (https://github.com/vergoh/vnstat/blob/master/src/daemon.c) starting from line 457. It will cause any updates to be ignored if the last know database update is in the future. If the difference is more than one day then the daemon exists. There is some discussion related to this in pull request #85.

Before you spend much time looking at the MonthRotate implementation, it could also be worth noting that the vnStat 2.0 branch (https://github.com/vergoh/vnstat/tree/sqldb) currently lacks the MonthRotate implementation completely due to everything related to database handling having been rewritten to support sqlite as database.