vnstat icon indicating copy to clipboard operation
vnstat copied to clipboard

Published 20 hours ago • verified publisher icon vergoh

Bug or user-error: Mac vnstat config not respected and database stability?

Open DarrenPIngram opened this issue 2 years ago • 5 comments

Installed vnstat to my Mac via "brew".

1 - It works but occasionally it seems to stop updating. Not figured out why as the machine is on 24x7.

Process so far:

verify running
        -
    restart of service:
        sudo brew services restart vnstat
    
    delete database & restart:
        sudo rm /usr/local/var/db/vnstat/vnstat.db

2 - It seems that the configuration file is not being respected.

Expected behaviour: Running vnstat should show only the stated (live) network port (en0).

Tested: Editing sudo nano /usr/local/etc/vnstat.conf Changing: ```

default interface (leave empty for automatic selection)

Interface "en0"


Output received:

MacPro:copyback di$ vnstat

                  rx      /      tx      /     total    /   estimated

EHC250: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

EHC253: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC26: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC29: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC58: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC61: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC90: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

UHC93: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

XHC0: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

en0: 2022-05 31.62 GiB / 2.17 TiB / 2.20 TiB / 6.52 TiB yesterday 10.57 GiB / 569.19 GiB / 579.75 GiB today 21.06 GiB / 1.62 TiB / 1.64 TiB / 3.49 TiB

en1: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

fw0: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

gif0: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

stf0: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

utun0: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --

utun1: 2022-05 0 B / 0 B / 0 B / --
yesterday 0 B / 0 B / 0 B today 0 B / 0 B / 0 B / --


I have tried both en0 and eth0 in the config.

En0 correctly shown by ifconfig.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=40b<RXCSUM,TXCSUM,VLAN_HWTAGGING,CHANNEL_IO> ether REDACTED inet6 REDACTED%en0 prefixlen 64 secured scopeid 0xe inet 192.168.0.90 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=201<PERFORMNUD,DAD> media: autoselect (1000baseT <full-duplex,flow-control>) status: active


Version: vnStat 2.9 by Teemu Toivola <tst at iki dot fi>


Now is this user error, or a bug? Guidance welcome.

DarrenPIngram avatar May 11 '22 08:05 DarrenPIngram

  1. Check what the daemon log contains. It may provide clues what's happening. It's also worth checking if the daemon is still running when you see the updates stop. If the daemon is still running then there's something causing it to either ignore traffic or being blocked from writing to the database. On the other hand, if the daemon stops running then there's either something killing it or it's exiting for some reason. The log should provide clues for most of these cases.

  2. The Interface setting in the configuration file applies only to those outputs which are interface specific. If no interface is specified on the command line with -i and Interface is left empty then vnstat -d (for example) will pick the interface with most traffic. However, if you execute just vnstat and there are multiple interfaces in the database then all those interface will be shown. If you have only one interface you are interested in tracking then it's suggested the remove the other interfaces from the database with vnstat --remove -i interface. If the database has only one interface then the regular one interface output will get used also for the summary.

vergoh avatar May 15 '22 20:05 vergoh

Sorry for the delayed response. Long-term sickness etc...

  1. Where might be the log be - sorry for the obvious question.
  2. Noted. Would there be scope, if you one day push changes, to have a configuration option only for explicit network interfaces to appear when vnstat is ran without explicit network ports added?

On Sun, 15 May 2022 at 23:35, Teemu Toivola @.***> wrote:

Check what the daemon log contains. It may provide clues what's happening. It's also worth checking if the daemon is still running when you see the updates stop. If the daemon is still running then there's something causing it to either ignore traffic or being blocked from writing to the database. On the other hand, if the daemon stops running then there's either something killing it or it's exiting for some reason. The log should provide clues for most of these cases. 2.

The Interface setting in the configuration file applies only to those outputs which are interface specific. If no interface is specified on the command line with -i and Interface is left empty then vnstat -d (for example) will pick the interface with most traffic. However, if you execute just vnstat and there are multiple interfaces in the database then all those interface will be shown. If you have only one interface you are interested in tracking then it's suggested the remove the other interfaces from the database with vnstat --remove -i interface. If the database has only one interface then the regular one interface output will get used also for the summary.

— Reply to this email directly, view it on GitHub https://github.com/vergoh/vnstat/issues/229#issuecomment-1127023167, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABV5MAHUHQDDL2CYPFNLFETVKFNZRANCNFSM5VUB43NA . You are receiving this because you authored the thread.Message ID: @.***>

DarrenPIngram avatar May 23 '22 05:05 DarrenPIngram

I'm not too familiar on how homebrew stores the log of the service processes it starts but based in this https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/vnstat.rb#L56 it looks like the daemon is being started in terminal attached mode. As a result, homebrew is responsible for the logging. Check if there's something like /usr/local/var/log/vnstat/ or similar available which would have the log output visible. Possibly sudo brew services info vnstat may also directly provide the log output or a clue where to look for it.

It's already possibly to change the daemon to behave in such way that it doesn't add all available interfaces by adding --noadd to the vnstatd parameters. However this needs to be also applied for the first startup since by default new interfaces don't get added if the database already has interfaces. It's also possible to request the daemon to just create an empty database (if none exists) using --initdb.

vergoh avatar May 29 '22 00:05 vergoh

I have a similar problem when installing on POP OS (which is ubuntu-derived. Tried editing /etc/vnstat.conf and restarting 'systemctl restart vnstat' and the new settings are not respected. I changed UseLogging to 1 and expected logs to appear in /var/log/vnstat/vnstst.log but nothing there. Changed Interface to "eno1" but vnstat is still monitoring all interfacses. I even edited the systemctl service file and added --config /etc/vnstat.conf , did a systemctl daemon-reload - still does not respect the changes in vnstat.conf and there are no log messages indicating why.

My expectation would be that if I change a setting in vnstat.conf by uncommenting and changing value then vnstst should emit a log message on if that setting is recognised and why the change has not been applied.

eccles avatar Aug 04 '22 11:08 eccles

@eccles UseLogging is only applicable when the daemon is started with -d or --daemon resulting in it no longer being attached to a terminal and therefore requiring some place to push the logs. When systemd is used, the process is started with -n or --nodaemon which results in the process staying attached to the terminal systemd provides and all the logging is handled by systemd as a result. Use systemctl status vnstat for getting the last few lines of log or journalctl -u vnstat for getting everything. I'll have to clarify this behaviour in the documentation since the UseLogging section in the vnstat.conf man page doesn't appear to currently mention this.

Interface in the configuration file doesn't define which interfaces the daemon is monitoring. It defines the default interface to be used for vnstat and vnstati commands if you don't use the -i parameter and there are more than one interfaces in the database. See the vnstat.conf man page for a longer description. As for removing interfaces from monitoring, use vnstat --remove -i interface (with sudo or root). The daemon will automatically detect the change during the next database write and stop monitoring those interfaces that are no longer in the database.

vergoh avatar Aug 04 '22 11:08 vergoh