1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Cstats keeps crashing

Discussion in 'Tomato Firmware' started by TheBigTomato, Dec 31, 2011.

  1. TheBigTomato

    TheBigTomato Networkin' Nut Member

    Not sure what I am doing wrong... I am running wallwatcher to capture this info from the router and this is the rtn message I am receiving

    2011/12/3112:35:53.13Mcstats[602]: problem loading /cifs1/tomato_cstats_586d8f684f1d.gz. still trying...

    I have checked the share and verified the permissions as read and write but for some oddball reason cstats will not read the file...

    I have the router set to reboot and save the log before shutting down and the backups are working by the looks of it as well. Any help on what I might have to do to get the per IP monthly bandwidth history to stay running would be appreciated.

    Manually restoring the data from the active log is not working...

    It works for about 27 days then craps out ... I am stumped

    Router/Version info:
    E4200

    Tomato Firmware v1.28.7489 MIPSR2-Toastman-RT K26 USB Ext
    - Linux kernel 2.6.22.19 and Broadcom Wireless Driver 5.10.142.0 updates
    - Support for additional router models, dual-band and Wireless-N mode.
    - USB support integration and GUI, IPv6 support,
    Copyright (C) 2008-2011 Fedor Kozhevnikov, Ray Van Tassle, Wes Campaigne
    http://www.tomatousb.org

    This compilation may also include:

    "Teddy Bear" current features, notably:
    - USB Support, Samba, FTP, Media Servers
    - Web Monitor, Per-connection transfer rates
    - Additional ipv6 support in GUI, QOS, Conntrack
    http://www.tomatousb.org

    "Victek RAF" features:
    - CPU Freq | Previous WAN IP
    - HFS/HFS+MAC OS x read support
    - Captive Portal (Based on NocatSplash)
    Copyright (C) 2007-2011 Vicente Soriano
    Captive Portal Copyright (C) 2011 Ofer Chen & Vicente Soriano
    http://victek.is-a-geek.com

    "Shibby" features:
    - Custom log file path
    - SD-idle tool integration for kernel 2.6
    - SNMP integration and GUI
    Copyright (C) 2011 MichaƂ Rupental
    http://openlinksys.info

    "JYAvenard" Features:
    - PPTP VPN client integration and GUI
    Copyright (C) 2010-2011 Jean-Yves Avenard
    jean-yves@avenard.org

    "Teaman" Features:
    - QOS-detailed & ctrate improved filters
    - Per-IP bandwidth monitoring of LAN clients [cstats v2]
    - Static ARP binding
    Copyright (C) 2011 Augusto Bott
    http://code.google.com/p/tomato-sdhc-vlan/

    "Toastman" Features:
    - 250 entry limit in Static DHCP & Wireless Filter
    - 500 entry limit in Access Restriction rules
    - Up to 80 QOS rules
    - IMQ based QOS/Bandwidth Limiter
    - Configurable QOS class names
    - Comprehensive QOS rule examples set by default
    - GPT support for HDD by Yaniv Hamo
    http://www.linksysinfo.org/forums/showthread.php?t=60304

    Development by Victek/PrinceAMD/Phykris/Shibby/Toastman/Teaman

    Based on Tomato Firmware v1.28
    Copyright (C) 2006-2010 Jonathan Zarate
    http://www.polarcloud.com/tomato/

    Built on Sat, 19 Nov 2011 21:22:11 +0700
     
  2. kthaddock

    kthaddock Network Guru Member

  3. TheBigTomato

    TheBigTomato Networkin' Nut Member

    Though I have not updated I was having these problems before I updated. I figured I would run back to the other version eventually but unless there is a change log i missed referring to cstats changes I not holding out much hope there. I have been reading and the issue I am having seems to be isolated as I have not found a specific thread on it just yet =\
     
  4. teaman

    teaman LI Guru Member

  5. TheBigTomato

    TheBigTomato Networkin' Nut Member

    Good info thank you .. looks like i have some more reading to do!
     
  6. teaman

    teaman LI Guru Member

    Here's the long story of how those patches came by:

    A few months ago, after I just had seen this great thing on Tomato DualWAN called 'IPTraffic monitoring', I decided on bringing that feature into tomatoUSB and started looking around for those sources. Since the nice people that wrote Tomato DualWAN don't seem have made their sources available anywhere, I sorta got pissed off about such GPL infringement and decided to start coding that whole thing myself.

    Shortly after I had basic IPTraffic functionality going on (I believe the very first page I wrote was the "Transfer Rates" page, ipt-details.asp), I had this thought about how interesting it might be to have those stats stored so we could look back at what was going on with a particular IP in the past... So I looked at rstasts, made some changes... and cstats was just born ;)

    For a while, everything seemed to be happening as expected: lots of problems and bugs, tons of errors I didn't understand at first... but since eventually most of them got fixed and/or worked around at some point, it was eventually pushed to the git repo and released. At the time, most save/load functionality was fine. However, since the beginning, there was a bug that I simply couldn't understand/reproduce easily as the circumstances were quite similar, but it didn't happened every single time: cstats historic data would sometimes get corrupted/lost whenever I was flashing/upgrading a new/test firmware version, which didn't seem to be a major show-stopper, specially since the whole thing was (and still) is labelled as experimental.

    Anyways: during the following weeks, I continued coding/writing/patching/hacking things and repeatedly flashed/upgraded my routers with new versions and... that data corruption problem seemed to be gone (for good!), as all historic data for cstats I had collected for several weeks... was still there whenever the router rebooted with new firmware.

    Fast-forward to a few weeks ago and we notice people reporting that particular issue with data corruption cstats. Some reports detailed lots of things such as size and complexity of the deployment... and since it was becoming clear that mysterious issue wasn't gone while all reasonable possible/plausible causes seemed to be accounted for, it was time to start looking for all the other non-obvious reasons why such might could be happening...

    One particular day I was chatting with mr. Toastman about these possible/non-obvious causes and he offered an chance of looking at a system where that issue was being experienced and gave me access to his router so I could look at it happening live. Cool.

    So when I logged in into his router, I found a system with plenty of RAM (128M), USB storage and a decent CPU, handling over a hundred devices on his network - which is somewhat different from what I've been used to: my dev box is a WRT54GL with an SDHC card mod and just 16M of RAM, known to just about a dozen devices. That meant a somewhat a different perspective when looking back at how far this whole IPTraffic/cstats thing had gone (yeah, I'm proud of my hacking!).

    And there I was: logged in into a somewhat powerful device, with unlimited shell access... time to test for things that either wouldn't be possible at all on my router and/or would usually freeze/crash/reboot it :). So I spent the next few mins fiddling with all things cstats could be doing wrong while loading data at startup and/or saving it when shutting down: I couldn't find any - just like any of the countless times I tried that same thing here, on my own router/deployment. Then, I had this strange idea of looking for all sorts of things happening in the environment around/beyond what cstats was supposed to be doing (perhaps something could be going wrong with that?).

    So this is the part the magic light bulb got lit: it was time to open about half a dozen extra SSH sessions and fire up different monitoring tools at the same time on each of them - being able to look at several different things as they happened was something I could never do on in real time on a small device with very few/restricted resources such as my own (although, I must say that writing code that runs on such limited hardware... sorta makes you constantly look for better ways to write code that is well optimized and/or make sure things can actually run fine on such devices!). Anyways, back to the story:

    Things started to put themselves together when I looked at his datafiles and noticed his backup files were were a couple of weeks older than they should be (inconsistent with the box uptime) and were larger/bigger than the last/most recent saved datafile. Those two things struck me as 'weird'. Also, the last saved datafile had an nice, round number for its size (something like exactly 8192 bytes or 8 KB, if I recall properly). That was weirder. Scratching my head for a few... and here's what I eventually figured:

    The 2+ weeks older backups thingie was about backups not being enabled on admin-ipt.asp, so the older/rotated backup datafiles staying untouched for many days was totally unrelated to the problem at hand. However, those other thingies regarding smaller size and the fact that corrupted gzipped datafile had exactly 8KB (or some-another-nice-round-number) puzzled me. Tried to uncompress that gzipped file to see what it looked like: had some sort of error and an uncompressed file. Looked at my own datafiles and found one of the backups was shorter than the others. I had just flashed a new FW version earlier that day. The problem was never gone: it just had not been noticed for a while. That got me thinking: maybe something fell short? But what and/or why?

    At some point, when I was looking into the code of router/rc/services.c, I noticed both rstats/cstats services would be 'started' pretty much the same way everywhere in the code, but those services would be stopped/shutdown in two different ways through the code (keep in mind most of the code inside router/rc/*.c was just cloned from references to rstats). Most of the time stop_cstats is called to stop it:
    Code:
    static void stop_cstats(void)
    (...)
    n = 60;
    while ((n-- > 0) && ((pid = pidof("cstats")) > 0)) {
        if (kill(pid, SIGTERM) != 0) break;
        sleep(1);
    }
    (...)
    
    When we're upgrading, we have:
    Code:
    if (strcmp(service, "upgrade") == 0) {
    (...)
    stop_upnp();
    killall("rstats", SIGTERM);
    killall("cstats", SIGTERM);
    killall("buttons", SIGTERM);
    stop_syslog();
    (...)
     
    
    Although those two pieces of code should basically achieve the same goal, they do slightly different things: when upgrading, we signal any processes called 'cstats' to terminate just once and move on immediately; when we're calling stop_cstats, we hit the find the PID of the first process called 'cstats' and hit it with SIGTERM (and we keep doing that once a second until we can't find any process still alive).

    While the first approach should be enough under most circumstances since when cstats/rstats catches that signal, both run their similar 'clean shutdown' routines, but it does not wait for anything before moving on and killing/stopping other stuff, which could be a problem (i.e. CIFS and USB mounts). The second approach goes one step further: it keeps hitting cstats once a second with SIGTERM until it's gone. So I wondered... what if we're taking more than one second to shutdown?!? What happens if we need to wait for a disk to spin-up and/or transfer our files over a slow network??!?!

    During the following days, a few things were attempted - see commits from December 13th to 17th :)
    http://repo.or.cz/w/tomato.git/shortlog/refs/heads/Teaman-IPTraffic

    So... this is the story...

    Cheers!
     
    Toastman likes this.
  7. TheBigTomato

    TheBigTomato Networkin' Nut Member

    Teaman, well dam my head felt like it was gonna explode but I think I got the concept that frequent KILL KILL KILL requests to the cstats/rstats hybrid is suspected that if a computer for some reason decides to pull a Gandolf you shall not pass a few times and keeps the file from being written it cause cstats to throw a fit and corrupt the data ... my log files for cstats are also 8KB with a big one of 16k the day before my failure... while rstats are only 1k I will update to the suggested version and give it another shot | anything I can do to help ya let me know and I will do what I can =)
     
  8. mailliw

    mailliw Reformed Router Member

    Sorry to revive such an old thread, but I was wondering whether the cstats problems everyone had have been resolved. I am still struggling with it - anything other than real-time simply won't work. Cstats itself only works when I tell it to create a new file (cstats --new). "cstats" in telnet does nothing - it doesn't load. And I just don't know where to turn next! I really would love to find out why it works with a new file but not with an old one (after a reboot, for example).

    Ideas welcome!
     
  9. Toastman

    Toastman Super Moderator Staff Member Member

    There have been a few updates and fixes to cstats recently, whether or not they will help in your particular instance, I'm not sure. Try downloading latest version from below (in my signature) and try it.
     
  10. mailliw

    mailliw Reformed Router Member

    Hi Toastman. Thanks for the reply and congrats on your work for Tomato. A lot of dedication.

    Is there a specific link to cstats that I could download? You said "below" - unless I'm blind, couldn't see it!

    I just installed asuswrt and cstats is working fine on that. So...just need to find out what that author did to make it work :)
     
  11. kthaddock

    kthaddock Network Guru Member

    Website: http://www.toastmanfirmware.yolasite.com
    Download site http://www.4shared.com/dir/v1BuINP3/Toastman_Builds.html (inc. torrent downloads)
    Build Guide http://www.linksysinfo.org/index.php?threads/toastman-firmware-build-guide.36113/
    Common Tomato Topics http://www.linksysinfo.org/index.php?threads/common-tomato-topics.31234/
    How to use QOS http://www.linksysinfo.org/index.php?threads/using-qos-tutorial-and-discussion.28349/
     
  12. mailliw

    mailliw Reformed Router Member

    Thanks. I'll give it another go. Just gone through the syslog for AsusWRT and cstats again isn't working. From what I can gather, this seems to be unique to Asus routers. I'm on a RT-N66U, and it's reporting:

    Jun 4 10:53:22 cstats[578]: Problem loading /tmp/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz. Still trying...

    It's a USB flash drive formatted to EXT3 (or EXT2, can't remember). The file is untarrable and corrupt, so whatever happens when cstats first writes it to disk seems to cause failure for Asus routers. At least, that's what I understand. The directory is writable (cstats and rstats create the file, after all), but I tried chmod 777 * to make sure. This is consistent with AsusWRT and Toastman.

    Happy to test anything if someone's looking into it

    Will
     
  13. kthaddock

    kthaddock Network Guru Member

    Have you tried this: " /mnt/Data/stats/ " as your link custom path? ( without quotas )
     
  14. mailliw

    mailliw Reformed Router Member

    Good idea, and initially it seemed to help - but not any more. I think I'm getting closer to debugging this though...

    From what I can tell, "cstats --new" is called after a reboot. Why this is, I don't know - whether because it's called before the USB drive mounts or not, I don't know. But because --new creates a new file, it therefore can't load any of the old .gz files (or, if it does, it finds it's blank), so it loops constantly.

    I checked this by doing

    Code:
    ps | grep "stats"
    Then killing the process. If I started it again by calling cstats (without the --new) flag, it seemed to load the gz tarball happily:

    Code:
    will@RT-N66U:/tmp/mnt/Data/stats# cstats
    cstats - Copyright (C) 2011-2012 Augusto Bott
    based on rstats - Copyright (C) 2006-2009 Jonathan Zarate
     
    load: new=0, uptime=705
    load: uptime = 11m, save_utime = 60m
    will@RT-N66U:/tmp/mnt/Data/stats# load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: found data for ip 192.168.0.0
    Node_new: new node ip=192.168.0.0, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.124
    Node_new: new node ip=192.168.0.124, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.144
    Node_new: new node ip=192.168.0.144, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.145
    Node_new: new node ip=192.168.0.145, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.16
    Node_new: new node ip=192.168.0.16, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.237
    Node_new: new node ip=192.168.0.237, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.56
    Node_new: new node ip=192.168.0.56, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.66
    Node_new: new node ip=192.168.0.66, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.71
    Node_new: new node ip=192.168.0.71, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: found data for ip 192.168.0.72
    Node_new: new node ip=192.168.0.72, version=842027858, sizeof(Node)=7920 (bytes)
    load_history_to_tree: loaded 10 records
    calc: cstats_exclude=''
    calc: cstats_include=''
    calc: sync[192.168.0.0]=-1
    calc: sync[192.168.0.0] changed to -1
    calc: counter[0]=0 ptr->last[0]=9499516
    calc: counter[1]=0 ptr->last[1]=26780784
    calc: sync[192.168.0.16]=-1
    calc: sync[192.168.0.16] changed to -1
    calc: counter[0]=0 ptr->last[0]=1931
    calc: counter[1]=0 ptr->last[1]=5342
    calc: sync[192.168.0.56]=-1
    calc: sync[192.168.0.56] changed to -1
    calc: counter[0]=0 ptr->last[0]=78977
    calc: counter[1]=0 ptr->last[1]=9558
    calc: sync[192.168.0.66]=-1
    calc: sync[192.168.0.66] changed to -1
    calc: counter[0]=0 ptr->last[0]=476
    calc: counter[1]=0 ptr->last[1]=5735
    calc: sync[192.168.0.71]=-1
    calc: sync[192.168.0.71] changed to -1
    calc: counter[0]=0 ptr->last[0]=31599
    calc: counter[1]=0 ptr->last[1]=14436
    calc: sync[192.168.0.72]=-1
    calc: sync[192.168.0.72] changed to -1
    calc: counter[0]=0 ptr->last[0]=55038
    calc: counter[1]=0 ptr->last[1]=15130
    calc: sync[192.168.0.124]=-1
    calc: sync[192.168.0.124] changed to -1
    calc: counter[0]=0 ptr->last[0]=34691
    calc: counter[1]=0 ptr->last[1]=25810
    calc: sync[192.168.0.144]=-1
    calc: sync[192.168.0.144] changed to -1
    calc: counter[0]=0 ptr->last[0]=67828
    calc: counter[1]=0 ptr->last[1]=21808
    calc: sync[192.168.0.145]=-1
    calc: sync[192.168.0.145] changed to -1
    calc: counter[0]=0 ptr->last[0]=65198
    calc: counter[1]=0 ptr->last[1]=48383
    calc: sync[192.168.0.237]=-1
    calc: sync[192.168.0.237] changed to -1
    calc: counter[0]=0 ptr->last[0]=9163984
    calc: counter[1]=0 ptr->last[1]=26634634
    calc: check exclude=''
    calc: ====================================
    
    When rebooting, it also seemed fine - writing it to disk:

    Code:
    will@RT-N66U:/tmp/mnt/Data/stats# save: quick=0
    save_history_from_tree: fname=/var/lib/misc/cstats-history
    save: saved 10 records from tree on file /var/lib/misc/cstats-history
    save: write source=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    save: cp /var/lib/misc/cstats-history.gz /mnt/Data/stats/tomato_cstats_60a44c2872e8.gz.tmp
    save: copy ok
    save: rename /mnt/Data/stats/tomato_cstats_60a44c2872e8.gz.tmp /mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    save: rename ok
    Connection to 192.168.0.1 closed by remote host.
    Connection to 192.168.0.1 closed.
    But once it loaded back up, it ran cstats --new and as you can see below, it can't find the (original?) files and loops continually:

    Code:
    ASUSWRT RT-N66U_3.0.0.4 Sun Mar 17 19:23:55 UTC 2013
    will@RT-N66U:/tmp/home/root# ps | grep "stats"
      556 will      1216 S    rstats --new
      572 will      992 S    cstats --new
    1341 will      1412 S    grep stats
    will@RT-N66U:/tmp/home/root# kill 572
    will@RT-N66U:/tmp/home/root# cstats
    cstats - Copyright (C) 2011-2012 Augusto Bott
    based on rstats - Copyright (C) 2006-2009 Jonathan Zarate
     
    load: new=0, uptime=63
    load: uptime = 1m, save_utime = 60m
    will@RT-N66U:/tmp/home/root# load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_2.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_2.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_2.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_2.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_1.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_1.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_1.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_1.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8.gz
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_5.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_4.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    load_history: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak
    load_history_to_tree: cstats_exclude=''
    load_history_to_tree: fname=/mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak
    gzip: /mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak: No such file or directory
    load_history_to_tree: gzip -dc /mnt/Data/stats/tomato_cstats_60a44c2872e8_3.bak > /var/tmp/cstats-uncomp != 0
    load_history_to_tree: loaded 0 records
    At least we now know the following:

    1) Teaman's cstats has no problem with writing to USB flash drives
    2) /tmp/mnt is fine to call, and write to. So is /mnt
    3) The files are readable
    4) On reboot, and/or process kill of cstats, the data cache is written to file

    What we don't know is:

    1) Why a reboot clears these files

    A mystery

    Will
     
  15. kthaddock

    kthaddock Network Guru Member

    What is this settings:?

    Save On Shutdown ?
    Create New File ?
    (Reset Data)
    Create Backups ?


    mine running as "root"
     
  16. mailliw

    mailliw Reformed Router Member

    I'm running as Will, not root...but I don't see that would affect anything.

    I'm on AsusWRT at the moment, so, I don't have "Save on Shutdown". If I tick "Create or reset data files", then they're created. The save frequency is hourly.
     
  17. mailliw

    mailliw Reformed Router Member

    FIXED: I am stupid. Should have checked Merlin's changelog. This particular cstats bug is documented by him here (thanks Merlin!). I installed the latest beta, 3.0.0.4.354.29 Beta 1 and, after two reboots, the IP traffic 24-hour stats are being retained. Hurrah!

    @rmerlin: will you be sharing your cstats fix (which seems to be about one line of code) to teaman and toastman?

    Thanks to all for listening, and to Merlin for his monstrous hard work

    Will
     
  18. RMerlin

    RMerlin Network Guru Member

    I didn't know at the time if Tomato also had the same issue, but here it is:

    https://github.com/RMerl/asuswrt-merlin/commit/741cb8cbe88273ccd552c31584a1257f71c881da

    Essentially, you need to write back the var to flash after modifying it. Otherwise, if the router gets rebooted without ever getting any nvram change requiring a commit (which happens especially when you are trying to debug cstats issue - how ironic!), it will never be committed back to flash.

    I had a similar issue with JFFS2 formatting:

    https://github.com/RMerl/asuswrt-merlin/commit/fbcc8cc2d167649e979fcd77095be34eeb17d4f7

    As for the cstats crashes, I fixed some crash issues a few months ago. Both cstats and the httpd daemon weren't properly manipulating the device list, causing both memory leaks and a chance to access an invalid pointer (which would probably be what was causing your crashes). These are already implemented in most Tomato builds now.

    EDIT: I see you referred to another cstats issue. This one is probably a matter of personal preferences, that's why I didn't submit the change to Tomato devs.

    https://github.com/RMerl/asuswrt-merlin/commit/51c29638d695a85c9e23d9104dbd986a6611a5eb
     
  19. mailliw

    mailliw Reformed Router Member

    Yes, I was going to say: the builds with the nvram fixes certainly helped, but that other issue (which is working beautifully by the way) seems to be prevalent among Asus users in particular. Would it not be relevant for the Tomato devs?
     
  20. RMerlin

    RMerlin Network Guru Member


    One difference (AFAIK) is that Tomato does make use of the backup feature, while I don't (yet - that's something I might look into in the future). So for the backup feature to be useful, you might want cstats to fallback on a backup if the main file doesn't contain any record (because it might be corrupted).
     
  21. mailliw

    mailliw Reformed Router Member

    Understood. But currently, Tomato is failing because the main file doesn't contain any records - and AFAIK, it will also fail the backup too (since they sometimes don't contain any records either).

    If you're willing to compile this I'm willing to test it :) No worries if you'd just rather wait for Toastman/Teaman.
     
  22. RMerlin

    RMerlin Network Guru Member


    I don't have a build environment setup for Tomato.
     
  23. Malitiacurt

    Malitiacurt Networkin' Nut Member

    Your copy of cstats backup is likely corrupt, move on and start recording with new builds than trying to restore it.
     
  24. mailliw

    mailliw Reformed Router Member

    But that's the point: the files are either becoming corrupted (poorly written before they are copied/backed up) not just for me but for most Asus owners! Deleting the backups doesn't help, it just confirms the problem.

    Anyway, nevermind. Not the end of the world! Thanks for everyone's input
     
  25. Toastman

    Toastman Super Moderator Staff Member Member

    Look for next BETA version, Kevin has made a few changes based on RMerlin's suggestion :)
     
    mailliw likes this.
  26. mailliw

    mailliw Reformed Router Member

    Thanks Toastman!
     
  27. mailliw

    mailliw Reformed Router Member

    Keep meaning to thank Kevin and you. It's working beautifully now.

    Quick question: would it ever be possible for Tomato to generate rstats and cstats graphs for daily/monthly time periods, in much the same way it does for 24 hours and realtime?
     
  28. Kevin Darbyshire-Bryant

    Kevin Darbyshire-Bryant Networkin' Nut Member

    I don't deserve any thanks at all. RMerlin is the guy who spent and *continues* to spend time on the cstats/ipt_accounting modules. He assures us there are more bugs to be squashed. I cut&pasted his commits into my branch, which then got merged into Toastman's branch & builds.

    I'll now cut&paste off.
     
  29. Toastman

    Toastman Super Moderator Staff Member Member

    We're a committed bunch of cut@pasters here, thanks to all of the coders and pasters that make this possible, to Teaman for the module in the first place, and to RMerlin for his dedication to fixing the remaining bugs! And to Kevin for contributing the code changes in his tomato test branch.

    Yes, it's obviously *possible* to do almost anything, but the existing graphs seem adequate for the majority of users. [Currently, my philosophy is based on "just because you CAN do something, doesn't mean you SHOULD" :) ]
     
    Monk E. Boy and M_ars like this.

Share This Page