[SOLVED] Time Warp breaking vnstat / net_monitor

[artificeprime]

Hey all, I've been wrestling with this issue for a few days now. Since moving to MGA3 (clean install) I'm getting some really gonzo behaviour from both vnstat and net_monitor on one box (the old x86 in my sig) while another (an x86_64 laptop with nearly identical configuration) appears to work fine. Apologies in advance if this post runs tl;dr.

What I'm experiencing is this: after boot vnstat refuses to update. One symptom is that the watched interface is always "disabled". Once enabled it still doesn't update because at boot vnstat's database gets set to UTC but once booted tries to update at local time (-0700 for my location). It refuses to update because the previous update took place 7 hours into the future (hence the "time warp" in my post title).

This adversely effects the net_monitor GUI as well, which under "Traffic Accounting" reports along the lines of "Connection Time: -7 hours, 59 minutes, 42 seconds". The bizarre thing about net_monitor is how "Connection Time" still appears to count away from zero instead of (if it were really negative) toward zero. What I mean to say is that if I wait for 18 seconds after the line above the output jogs to "Connection Time: -6 hours, 0 minutes, 0 seconds" instead of "Connection Time: -7 hours, 59 minutes, 24 seconds" as I would expect.

The only way I can work around this issue is to enable the interface manually via vnstat as root at the CLI and then restart the service altogether. This needs to be done after every boot.

So I've been wondering if this might be caused by the order in which ntpd and vnstatd are started (if that's it, I have no clue how to change it), or if this might have to do with the shorewall6 kerfuffle that's breaking drakfirewall — i.e. vnstat b0rked when I changed some settings. If you don't know what I'm referring to see Errata §4.4, this forum post, Bug 9941 (starting at Comment 2), plus a whole host of other bug reports 9329, 9723; 10155.

Anyway, I thought I'd bring this up on the forums before posting formal bug reports. Any help appreciated.

Show-and-tell of my CLI output follows, starting with my allaying the two most basic concerns.

Yes, both packages are installed:

Code: Select all

$ rpm -qa '*vnstat*' '*net_monitor*'
vnstat-1.11-2.mga3
net_monitor-0.11-5.mga3

Yes, vnstatd is set to start at boot and is running (note the process's start time @ 12:05:

Code: Select all

$ ps -ef | grep vnstatd
root       729     1  0 12:05 ?        00:00:00 /usr/sbin/vnstatd -d

If I ask vnstat what it's up to (note the update time is 7 hours into the future and that the interface is "disabled"):

Code: Select all

$ vnstat
Database updated: Sun Jun  9 19:05:25 2013

   eth0 [disabled] since 06/04/13

          rx:  6.57 GiB      tx:  2.80 GiB      total:  9.36 GiB

   monthly
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      Jun '13       6.57 GiB |    2.80 GiB |    9.36 GiB |  103.35 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated     22.39 GiB |    9.54 GiB |   31.93 GiB |

   daily
                     rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      06/07/13      2.67 GiB |  822.80 MiB |    3.47 GiB |  336.84 kbit/s
      06/08/13    226.63 MiB |  262.18 MiB |  488.81 MiB |   58.27 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated       284 MiB |     329 MiB |     613 MiB |

I su to root, enable the interface, and try to update it:

Code: Select all

# vnstat --enable -i eth0
# vnstat -u -i ehth0
Error: The previous update was after the current date.
Use --force to override this message.

[doktor5000]

Please show the output of

Code: Select all

timedatectl

[artificeprime]

Certainly, sir.

Code: Select all

# timedatectl
      Local time: Sun, 2013-06-09 14:49:50 MST
  Universal time: Sun, 2013-06-09 21:49:50 UTC
        RTC time: Sun, 2013-06-09 21:49:50
        Timezone: n/a
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: yes

Warning: The RTC is configured to maintain time in the local time zone. This
         mode is not fully supported and will create various problems with time
         zone changes and daylight saving adjustments. If at all possible use
         RTC in UTC, by calling 'timedatectl set-local-rtc 0'.

As it happens I've (re)discovered something that fixed a similar (if not this very same) issue in Mageia 2... and it was brought to your very attention by another forum user some 6 months ago.

I'll let you know how it work out. Experiment requires a reboot. BRB.

[doktor5000]

As it happens I've (re)discovered something that fixed a similar (if not this very same) issue in Mageia 2... and it was brought to your very attention by another forum user some 6 months ago.

Please also provide a link, thanks - can't remember all threads here

[artificeprime]

Please also provide a link, thanks - can't remember all threads here

Nor would I expect you to, but I thought I'd keep you in suspense for a bit.

Unfortunately the experiment proved disappointing, which is to say it fixed squat.

As for what I tried and the link, it's this one posted last Christmas by bazyli concerning the probable "ayes" vs "yes" typos in the vnstat and net_monitor network scripts which prevented Mageia 1 & 2 from properly starting and updating vnstat. Though at the time, you couldn't confirm this as an actual problem, I experienced it on all my Mageia 2 machines (including this very same machine I'm fighting with again) and implementing bazyli's edits fixed them.

I'd completely forgotten about it until today, but I can verify that these alleged typos (which IIRC we inherited from Mandriva/ROSA) still persist in Mageia 3:

Code: Select all

# cd /etc/sysconfig/network-scripts/
# find . -type f -exec grep -H 'ayes' {} \;
./ifup.d/vnstat_ip-up:  if [ "a$ACCOUNTING" = "ayes" ]; then
./ifup.d/netmonitor_up: if [ "a$ACCOUNTING" = "ayes" ]; then
./ifdown.d/netmonitor_down:     if [ "a$ACCOUNTING" = "ayes" ]; then
./ifdown.d/vnstat_ip-down:      if [ "a$ACCOUNTING" = "ayes" ]; then


I absolutely agree with balysi that these must be typos (note the second last line):

Code: Select all

# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=static
IPADDR=192.168.1.249
NETMASK=255.255.255.248
GATEWAY=192.168.1.254
ONBOOT=yes
METRIC=5
MII_NOT_SUPPORTED=no
USERCTL=yes
DNS1=192.168.1.254
DNS2=192.168.1.254
RESOLV_MODS=no
IPV6INIT=no
IPV6TO4INIT=no
ACCOUNTING=yes
NM_CONTROLLED=yes

I changed the occurrences of "a$ACCOUNTING" = "ayes" to "$ACCOUNTING" = "yes" in all four files and rebooted (I believe the leading "a" in front of the "$" is also erroneous and removed them from the Mageia 2 scripts at the time).

But as I indicated above, it didn't change the behaviour of my current issue. vnstat's database time is still wrong and the interface is disabled on boot.

Even if it had resolved the issue, the mystery would have remained as to why my x86_64 laptop works okay even with the alleged typos in its network scripts (corroborating your inability to confirm that issue 6 months ago on Mageia 2 even though it set all my machines straight at the time).

Gah!!! This is so perplexing.

[doktor5000]

Well, at least https://wiki.mageia.org/en/Mageia_2_Err ... es_nothing still persists.
Just installed vnstat and net_monitor, launched accounting thing - and it works.

Apart from that, you may want to do the steps from the script manually.
That is, check if /var/lib/vnstat/ is writable for root:

Code: Select all

ls -ald /var/lib/vnstat/

Then check if the database can be created manually, start monitoring and reload vnstat:

Code: Select all

/usr/bin/vnstat -u -i eth0
/usr/bin/vnstat -r --enable -i  eth0
service vnstat force-reload

[artificeprime]

Hey, hey, doktor5000 you did it! You fixed my issue!!!

I figured I'd struggle against the time warp some more today. Tried a few things (removing the interface, adding it back, removing shorewall-ipv6 again, etc.) and compared everything vnstat and net_monitor related I could think of between this machine and the working one. Nothing. No differences. I maintain I set both of them up identically (!) Except for hardware, they're identical in every way....

...but since you'd asked me to output timedatectl on this machine I tried it on the working one.

Code: Select all

 RTC in local TZ: no

And not followed by the big "blah, blah, blah" WARNING! about RTC stuff which I didn't really pay much attention to yesterday.

So I actually bothered to read the warning today and figured, what the heck:

Code: Select all

# timedatectl set-local-rtc 0

Reboot....

And that was it. Good grief! After all that frustration and gnashing of teeth, both apps work as advertised again with a 2 second fix. I don't even know what that RTC business is, or how it got activated on this machine. I swear both machines should be identical.

Anyway doktor, thanks again!

[doktor5000]

No problem