Daily Bandwidth dates/time GMT instead of timezone?

Discussion in 'Tomato Firmware' started by bjlockie, Jan 27, 2018.

  1. bjlockie

    bjlockie Network Guru Member

    I noticed the "Daily Bandwidth" date goes to the next day before the time is midnight.
    I suspect it is logging the GMT instead of the local timezone time.
    Can anyone explain what I am seeing?
  2. Sean B.

    Sean B. LI Guru Member

    Have you set your time zone and ( if applicable ) daylight savings under Basic->Time in the web interface?
  3. bjlockie

    bjlockie Network Guru Member

    The problem is the bandwidth logs roll over to a new day before it is a new day?
    I do use AdvancedTomato but would that be the cause?
    I suspect the logging is not using the timezone I have configured.
    No one has seen it start logging the next day before it is the next day?
  4. bjlockie

    bjlockie Network Guru Member

    Does anyone see the same thing?
  5. eibgrad

    eibgrad Network Guru Member

    How soon before midnight are we talking? Milliseconds? Secs? Mins? Is it always on the hour?
  6. koitsu

    koitsu Network Guru Member

    I'm curious what this problem report means as well. No offense intended in the least, but so far I have seen no actual hard data (files, screenshots, anything). I believe the claim, but hard data is needed.

    Where are you seeing this information? Bandwidth -> Daily -> Data link on far right?

    The rstats daemon is responsible for bandwidth logging management.

    rstats uses localtime(3), not gmtime(3). Code reference: https://github.com/tomatofirmware/tomato/blob/tomato/release/src/router/rstats/rstats.c#L632

    ...thus it's subject to whatever the local timezone is on the router. What does that mean? BSD, GNU libc, and uClibc -- what TomatoUSB uses -- all differ slightly in their implementation of localtime(3).

    localtime(3) is subject to whatever the local timezone is. This is usually done via tzset(3), but on BSD and uClibc you can also use the environment variable TZ to define the timezone -- and furthermore, on uClibc, you can also use the file /etc/TZ to define it: https://www.uclibc.org/FAQ.html#timezones

    On Tomato, /etc/TZ is created based on what you pick in Basic -> Time in the GUI. The TZ environment variable is not used when rstats is launched/run from rc/init. I verified the latter by looking at /proc/{pid-of-rstats}/environ and ensuring there's no TZ variable. This file does contain NULLs, so you may want to use something like xxd (from Entware-ng) to "view" it; cat will work fine but individual variables will visually "run together".

    rstats does not have any debug or troubleshooting logging enabled by default, I'm sorry to say. It's _dprintf() calls are no-ops unless DEBUG_NOISY is #defined (either globally during compile-time in the project, or within that file itself). This makes rstats debugging painful. Though somewhere in the back of my mind I thought I remember seeing a

    Seeing output from nvram show | grep rstats would be helpful (you can ignore any interspersed lines saying "size: NNNN bytes (NNNN left)"). I know rstats_offset is used for some calculations, but it's usually 1 for most people.

    The only other command I can think of that would verify timezone -- sort of -- on Tomato would be /bin/date -R and look closely the UTC offset at the end. Such as on my system, the time is presently Pacific Standard Time (PST), which is UTC-0800 (PDT is UTC-0700 and will happen once DST kicks in):

    root@gw:/tmp/home/root# cat /etc/TZ
    root@gw:/tmp/home/root# /bin/date -R
    Tue, 06 Feb 2018 18:46:59 -0800
    root@gw:/tmp/home/root# pidof rstats
    root@gw:/tmp/home/root# xxd /proc/964/environ
    00000000: 484f 4d45 3d2f 0054 4552 4d3d 7674 3130  HOME=/.TERM=vt10
    00000010: 3000 5041 5448 3d2f 7362 696e 3a2f 6269  0.PATH=/sbin:/bi
    00000020: 6e3a 2f75 7372 2f73 6269 6e3a 2f75 7372  n:/usr/sbin:/usr
    00000030: 2f62 696e 3a2f 6f70 742f 7362 696e 3a2f  /bin:/opt/sbin:/
    00000040: 6f70 742f 6269 6e00 5348 454c 4c3d 2f62  opt/bin.SHELL=/b
    00000050: 696e 2f73 6800 5553 4552 3d72 6f6f 7400  in/sh.USER=root.
  7. Elfew

    Elfew Network Guru Member

  8. koitsu

    koitsu Network Guru Member

    Per a different thread: "P.S. I'm not really back, I'm just wasting 24-48 hours before continuing to apply for full-time work. You shouldn't expect to see me around past Wed or Thu this week at the latest."
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice