SYNOPSIS<\/a>
DESCRIPTION<\/a>
OPTIONS<\/a>
CONFIGURATION<\/a>
SIGNALS<\/a>
FILES<\/a>
RESTRICTIONS<\/a>
AUTHOR<\/a>
SEE ALSO<\/a> <\/p>\n
\n
NAME <\/a> <\/h2>\nvnstatd \u2212 daemon based database updating for vnStat<\/p>\n
SYNOPSIS <\/a> <\/h2>\nvnstatd<\/b> [\u2212Ddnpsv?<\/b>] [\u2212\u2212alwaysadd<\/b>] [\u2212\u2212config<\/b> file<\/i>] [\u2212\u2212daemon<\/b>] [\u2212\u2212debug<\/b>] [\u2212g<\/b> group<\/i>] [\u2212\u2212group<\/b> group<\/i>] [\u2212\u2212help<\/b>] [\u2212\u2212noadd<\/b>] [\u2212\u2212nodaemon<\/b>] [\u2212\u2212pidfile<\/b> file<\/i>] [\u2212\u2212sync<\/b>] [\u2212\u2212u<\/b> user<\/i>] [\u2212\u2212user<\/b> user<\/i>] [\u2212\u2212version<\/b>]<\/p>\nDESCRIPTION <\/a> <\/h2>\nThe purpose of vnstatd<\/b> is to provide a flexible and robust way for updating the database that vnstat<\/b>(1) uses. The availability of each interface is automatically tracked which removes the need for additional scripts to be implemented and called when an interface comes online or goes offline.<\/p>\n
vnstatd<\/b> is the command for starting the daemon. The daemon can either fork itself to run as a background process or stay attached to the terminal. It supports logging to a user selectable file or using syslog.<\/p>\n
Once started, the daemon will read vnstat.conf<\/b>(5) if available and then check if there is a database present in the database directory that has been specified in the configuration file. By default, if no database is found, a database will be created during startup with entries for all available interfaces excluding pseudo interfaces lo, lo0 and sit0. This automatic database entry creation behaviour can be disabled using the –noadd<\/b> option. Alternatively, it is possible to allow the daemon to create new database entries whenever previously unseen interfaces become visible using the –alwaysadd<\/b> option.<\/p>\n
The daemon will proceed to track the availability of monitored interfaces, process the interface traffic statistics and write new values to the database at a configured interval. As a result, the daemon ends up spending most of the time sleeping between updates.<\/p>\n
OPTIONS <\/a> <\/h2>\n–alwaysadd<\/b><\/p>\n
Enable automatic creation of new database entries for previously unseen interfaces even if the database directory already contains a database when the daemon is started. New database entries will also get created for new interfaces seen while the daemon is running. Pseudo interfaces lo, lo0 and sit0 are excluded from getting added.<\/p>\n
–config<\/b> file<\/i><\/p>\n
Use file<\/i> as configuration file instead of using automatic configuration file search functionality.<\/p>\n
-d, –daemon<\/b><\/p>\n
Fork process to background and run as a daemon.<\/p>\n
-D, –debug<\/b><\/p>\n
Provide additional output for debug purposes. The process will stay attached to the terminal for output.<\/p>\n
-g, –group<\/b> group<\/i><\/p>\n
Set daemon process group to group<\/i> during startup. group<\/i> can be either the name of the group or a numerical group id. This option can only be used when the process is started as root.<\/p>\n
–noadd<\/b><\/p>\n
Disable automatic creation of new database entries for all available interfaces if the daemon is started with no database found. Pseudo interfaces lo, lo0 and sit0 are excluded from getting added.<\/p>\n
-n, –nodaemon<\/b><\/p>\n
Stay in foreground attached to the current terminal and start the update process.<\/p>\n
-p, –pidfile<\/b> file<\/i><\/p>\n
Write the process id to file<\/i> and use it for locking so that another instance of the daemon cannot be started if the same file<\/i> is specified.<\/p>\n
-s, –sync<\/b><\/p>\n
Synchronize internal counters in the database with interface counters for all available interfaces before starting traffic monitoring. Use this option if the traffic between the previous shutdown and the current startup of the daemon needs to be ignored. This option isn\u2019t required in normal use because the daemon will automatically synchronize the internal counters after a system reboot, if enough time has passed since the daemon was previously running or if the internal counters are clearly out of sync.<\/p>\n
-u, –user<\/b> user<\/i><\/p>\n
Set daemon process user to user<\/i> during startup. user<\/i> can be either the login of the user or a numerical user id. This option can only be used when the process is started as root.<\/p>\n
-v, –version<\/b><\/p>\n
Show current version of the daemon executable.<\/p>\n
-?, –help<\/b><\/p>\n
Show a command option summary.<\/p>\n
CONFIGURATION <\/a> <\/h2>\nThe behaviour of the daemon is configured mainly using the configuration keywords UpdateInterval, PollInterval<\/b> and SaveInterval<\/b> in the configuration file.<\/p>\n
UpdateInterval<\/b> defines in seconds how often the interface data is fetched and updated. This is similar to the run interval for alternative cron based updating. However, the difference is that the data doesn\u2019t directly get written to disk during updates.<\/p>\n
PollInterval<\/b> defines in seconds how often the list of available interfaces is checked for possible changes. The minimum value is 2 seconds and the maximum 60 seconds. PollInterval<\/b> also defines the resolution for other intervals.<\/p>\n
SaveInterval<\/b> defines in minutes how often cached interface data is written to disk. A write can only occur during the updating of interface data. Therefore, the value should be a multiple of UpdateInterval<\/b> with a maximum value of 60 minutes.<\/p>\n
The default values of UpdateInterval<\/b> 30, SaveInterval<\/b> 5 and PollInterval<\/b> 5 are usually suitable for most systems and provide a similar behaviour as cron based updating does but with a better resolution for interface changes and fast interfaces.<\/p>\n
For embedded and\/or low power systems more tuned configurations are possible. In such cases if the interfaces are mostly static the PollInterval<\/b> can be increased to around 10-30 seconds and UpdateInterval<\/b> set to 60 seconds. Higher values up to 300 seconds are possible if the interface speed is 10 Mbit or less. SaveInterval<\/b> can be increased for example to 15, 30 or even 60 minutes depending on how often the data needs to be viewed.<\/p>\nSIGNALS <\/a> <\/h2>\nThe daemon is listening to signals SIGHUP, SIGINT<\/b> and SIGTERM.<\/b> Sending the SIGHUP<\/b> signal to the daemon will cause cached data to be written to disk, a rescan of the database directory and a reload of settings from the configuration file. However, the pid file location will not be changed even if it\u2019s configuration setting has been modified.<\/p>\n
SIGTERM<\/b> and SIGINT<\/b> signals will cause the daemon to write all cached data to disk and then exit.<\/p>\nFILES <\/a> <\/h2>\n\/var\/lib\/vnstat\/<\/i><\/p>\n
Default database directory.<\/p>\n
\/etc\/vnstat.conf<\/i><\/p>\n
Config file that will be used unless $HOME\/.vnstatrc<\/i> exists. See the configuration chapter and vnstat.conf<\/b>(5) for more information.<\/p>\n
\/var\/log\/vnstat.log<\/i><\/p>\n
Log file that will be used if logging to file is enable and no other file is specified in the config file.<\/p>\n
\/run\/vnstat\/vnstat.pid<\/i><\/p>\n
File used for storing the process id if no other file is specified in the configuration file or using the command line parameter.<\/p>\n
RESTRICTIONS <\/a> <\/h2>\nUpdates need to be executed at least as often as it is possible for the interface to generate enough traffic to overflow the kernel interface traffic counter. Otherwise, it is possible that some traffic won\u2019t be seen. With 32-bit kernels, the maximum time between two updates depends on how fast the interface can transfer 4 GiB. Calculated theoretical times are:<\/p>\n
![\"Image](\"grohtml-1040101.png\")
<\/p>\n
However, for 1000 Mbit interfaces updating once every minute is usually a usable solution if a shorter update interval can\u2019t be used.<\/p>\n
Virtual and aliased interfaces cannot be monitored because the kernel doesn\u2019t provide traffic information for that type of interfaces. Such interfaces are usually named eth0:0, eth0:1, eth0:2 etc. where eth0 is the actual interface being aliased.<\/p>\n
AUTHOR <\/a> <\/h2>\n
vnstatd<\/b> [\u2212Ddnpsv?<\/b>] [\u2212\u2212alwaysadd<\/b>] [\u2212\u2212config<\/b> file<\/i>] [\u2212\u2212daemon<\/b>] [\u2212\u2212debug<\/b>] [\u2212g<\/b> group<\/i>] [\u2212\u2212group<\/b> group<\/i>] [\u2212\u2212help<\/b>] [\u2212\u2212noadd<\/b>] [\u2212\u2212nodaemon<\/b>] [\u2212\u2212pidfile<\/b> file<\/i>] [\u2212\u2212sync<\/b>] [\u2212\u2212u<\/b> user<\/i>] [\u2212\u2212user<\/b> user<\/i>] [\u2212\u2212version<\/b>]<\/p>\n The purpose of vnstatd<\/b> is to provide a flexible and robust way for updating the database that vnstat<\/b>(1) uses. The availability of each interface is automatically tracked which removes the need for additional scripts to be implemented and called when an interface comes online or goes offline.<\/p>\n vnstatd<\/b> is the command for starting the daemon. The daemon can either fork itself to run as a background process or stay attached to the terminal. It supports logging to a user selectable file or using syslog.<\/p>\n Once started, the daemon will read vnstat.conf<\/b>(5) if available and then check if there is a database present in the database directory that has been specified in the configuration file. By default, if no database is found, a database will be created during startup with entries for all available interfaces excluding pseudo interfaces lo, lo0 and sit0. This automatic database entry creation behaviour can be disabled using the –noadd<\/b> option. Alternatively, it is possible to allow the daemon to create new database entries whenever previously unseen interfaces become visible using the –alwaysadd<\/b> option.<\/p>\n The daemon will proceed to track the availability of monitored interfaces, process the interface traffic statistics and write new values to the database at a configured interval. As a result, the daemon ends up spending most of the time sleeping between updates.<\/p>\n –alwaysadd<\/b><\/p>\n Enable automatic creation of new database entries for previously unseen interfaces even if the database directory already contains a database when the daemon is started. New database entries will also get created for new interfaces seen while the daemon is running. Pseudo interfaces lo, lo0 and sit0 are excluded from getting added.<\/p>\n –config<\/b> file<\/i><\/p>\n Use file<\/i> as configuration file instead of using automatic configuration file search functionality.<\/p>\n -d, –daemon<\/b><\/p>\n Fork process to background and run as a daemon.<\/p>\n -D, –debug<\/b><\/p>\n Provide additional output for debug purposes. The process will stay attached to the terminal for output.<\/p>\n -g, –group<\/b> group<\/i><\/p>\n Set daemon process group to group<\/i> during startup. group<\/i> can be either the name of the group or a numerical group id. This option can only be used when the process is started as root.<\/p>\n –noadd<\/b><\/p>\n Disable automatic creation of new database entries for all available interfaces if the daemon is started with no database found. Pseudo interfaces lo, lo0 and sit0 are excluded from getting added.<\/p>\n -n, –nodaemon<\/b><\/p>\n Stay in foreground attached to the current terminal and start the update process.<\/p>\n -p, –pidfile<\/b> file<\/i><\/p>\n Write the process id to file<\/i> and use it for locking so that another instance of the daemon cannot be started if the same file<\/i> is specified.<\/p>\n -s, –sync<\/b><\/p>\n Synchronize internal counters in the database with interface counters for all available interfaces before starting traffic monitoring. Use this option if the traffic between the previous shutdown and the current startup of the daemon needs to be ignored. This option isn\u2019t required in normal use because the daemon will automatically synchronize the internal counters after a system reboot, if enough time has passed since the daemon was previously running or if the internal counters are clearly out of sync.<\/p>\n -u, –user<\/b> user<\/i><\/p>\n Set daemon process user to user<\/i> during startup. user<\/i> can be either the login of the user or a numerical user id. This option can only be used when the process is started as root.<\/p>\n -v, –version<\/b><\/p>\n Show current version of the daemon executable.<\/p>\n -?, –help<\/b><\/p>\n Show a command option summary.<\/p>\n The behaviour of the daemon is configured mainly using the configuration keywords UpdateInterval, PollInterval<\/b> and SaveInterval<\/b> in the configuration file.<\/p>\n UpdateInterval<\/b> defines in seconds how often the interface data is fetched and updated. This is similar to the run interval for alternative cron based updating. However, the difference is that the data doesn\u2019t directly get written to disk during updates.<\/p>\n PollInterval<\/b> defines in seconds how often the list of available interfaces is checked for possible changes. The minimum value is 2 seconds and the maximum 60 seconds. PollInterval<\/b> also defines the resolution for other intervals.<\/p>\n SaveInterval<\/b> defines in minutes how often cached interface data is written to disk. A write can only occur during the updating of interface data. Therefore, the value should be a multiple of UpdateInterval<\/b> with a maximum value of 60 minutes.<\/p>\n The default values of UpdateInterval<\/b> 30, SaveInterval<\/b> 5 and PollInterval<\/b> 5 are usually suitable for most systems and provide a similar behaviour as cron based updating does but with a better resolution for interface changes and fast interfaces.<\/p>\n For embedded and\/or low power systems more tuned configurations are possible. In such cases if the interfaces are mostly static the PollInterval<\/b> can be increased to around 10-30 seconds and UpdateInterval<\/b> set to 60 seconds. Higher values up to 300 seconds are possible if the interface speed is 10 Mbit or less. SaveInterval<\/b> can be increased for example to 15, 30 or even 60 minutes depending on how often the data needs to be viewed.<\/p>\n The daemon is listening to signals SIGHUP, SIGINT<\/b> and SIGTERM.<\/b> Sending the SIGHUP<\/b> signal to the daemon will cause cached data to be written to disk, a rescan of the database directory and a reload of settings from the configuration file. However, the pid file location will not be changed even if it\u2019s configuration setting has been modified.<\/p>\n SIGTERM<\/b> and SIGINT<\/b> signals will cause the daemon to write all cached data to disk and then exit.<\/p>\n \/var\/lib\/vnstat\/<\/i><\/p>\n Default database directory.<\/p>\n \/etc\/vnstat.conf<\/i><\/p>\n Config file that will be used unless $HOME\/.vnstatrc<\/i> exists. See the configuration chapter and vnstat.conf<\/b>(5) for more information.<\/p>\n \/var\/log\/vnstat.log<\/i><\/p>\n Log file that will be used if logging to file is enable and no other file is specified in the config file.<\/p>\n \/run\/vnstat\/vnstat.pid<\/i><\/p>\n File used for storing the process id if no other file is specified in the configuration file or using the command line parameter.<\/p>\n Updates need to be executed at least as often as it is possible for the interface to generate enough traffic to overflow the kernel interface traffic counter. Otherwise, it is possible that some traffic won\u2019t be seen. With 32-bit kernels, the maximum time between two updates depends on how fast the interface can transfer 4 GiB. Calculated theoretical times are:<\/p>\n However, for 1000 Mbit interfaces updating once every minute is usually a usable solution if a shorter update interval can\u2019t be used.<\/p>\n Virtual and aliased interfaces cannot be monitored because the kernel doesn\u2019t provide traffic information for that type of interfaces. Such interfaces are usually named eth0:0, eth0:1, eth0:2 etc. where eth0 is the actual interface being aliased.<\/p>\nDESCRIPTION <\/a> <\/h2>\n
OPTIONS <\/a> <\/h2>\n
CONFIGURATION <\/a> <\/h2>\n
SIGNALS <\/a> <\/h2>\n
FILES <\/a> <\/h2>\n
RESTRICTIONS <\/a> <\/h2>\n
<\/p>\nAUTHOR <\/a> <\/h2>\n