Closed DarrenPIngram closed 2 years ago
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.
Sorry for the delayed response. Long-term sickness etc...
On Sun, 15 May 2022 at 23:35, Teemu Toivola @.***> wrote:
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.
— 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: @.***>
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
.
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
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.
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:
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"
MacPro:copyback di$ vnstat
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 / --
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