From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Updating 'vnstat' to 2.6 - need some help with necessary changes Date: Mon, 23 Mar 2020 08:29:32 +0000 Message-ID: <41B80EB9-24FB-48C4-967C-6268CCC1098D@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0315428615462558419==" List-Id: --===============0315428615462558419== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for looking into this. > On 22 Mar 2020, at 12:08, Matthias Fischer = wrote: >=20 > Hi, >=20 > I successfully built 'vnstat 2.6' under Core 142/32bit. >=20 > Right now a test version is running on my testmachine under Core 138 - > no seen problems. >=20 > Upgrading lfs and rootfile was enough for building, but I'm struggling > (a bit) with the necessary changes in some IPFire scripts. So I'm asking > here if there are ideas how to do this the best way. >=20 > Be warned, this is long... ;-) >=20 > Situation: > 1. Building is fine, but since 'vnstat 2.0' "C struct dump database has > been replaced with sqlite database". > See: > [humdi-URL deleted ... Thanks Peter!] >=20 > This is one of the most important changes! The old interface files > '.green0', 'red0' etc. are only needed *once* after the update. After a > successful update and import (this is done automatically at the first > start of 'vnstatd -d --alwaysadd', see below), these files are obsolete > and can be deleted. >=20 > What I changed by hand to get this running: > 1. GIT: Added '/usr/sbin/vnstatd' to rootfile. The new version needs it. >=20 > 2. GIT: Deleted 'touch /var/log/vnstat/tag' from lfs and > '/var/log/vnstat/tag' from rootfile. >=20 > *Question*: > Perhaps the 'sed'-line in 'lfs' replacing 'eth0' with 'green0' can be > deleted, too ("leave empty for automatic selection")!? >=20 > 3. Deleted the following lines from '/usr/local/bin/makegraphs': > ... > ## Update vnstat > system ('/usr/bin/vnstat -u'); > ... >=20 > 4. Stopped 'vnstat' and 'collectd' (to be sure, I stopped both, perhaps > only stopping 'vnstat' is needed here). >=20 > 5. Installed the new files on my testmachine: > /etc/vnstat.conf > /usr/bin/vnstat > /usr/bin/vnstati > /usr/sbin/vnstatd >=20 > 6. Started 'vnstatd -d --alwaysadd'. > '-d' =3D> fork process to background > '--alwaysadd' =3D> always add new interfaces even when some dbs exist >=20 > *Result*: > ... > [root(a)ipfiretest vnstat]# vnstatd -d --alwaysadd > Importing data from legacy database "green0". > Importing data from legacy database "blue0". > Importing data from legacy database "red0". > No interfaces found in database, adding available interfaces... > ... >=20 > This created a new file: '/var/log/vnstat/vnstat.db' (SQL - see above), > plus 'vnstatd' running in background with a PID. I suppose it makes a lot of sense to migrate to vnstatd instead of running = =E2=80=9Cvnstat -u=E2=80=9D from cron. > *Question*: > Where and how should the start/stop/reload of 'vnstatd' be added? > I think of adding appopriate commands to '/etc/initd/vnstat' but can't > get a grip on this. Would need some help with this. >=20 > Possibilities (from 'man vnstatd'): > "SIGNALS > The daemon is listening to signals SIGHUP, SIGINT and SIGTERM. Sending > the SIGHUP 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's configuration setting has been modified. >=20 > SIGTERM and SIGINT signals will cause the daemon to write all cached > data to disk and then exit." >=20 > start section would need: > 'vnstatd -d --alwaysadd' Yes, you can simply use the standard functions that our initscripts have here. https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/syste= m/template;h=3D69dc2a6a2202fb30da61a7fff6625aea531802e9;hb=3DHEAD loadproc will start the daemon and print =E2=80=9COK=E2=80=9D. > stop section: > SIGTERM or SIGINT (tested with 'htop' sending SIGTERM: works) killproc will send SIGTERM. > reload section (if config was changed): > SIGHUP reloadproc will handle this for you :) > How to do this the best way? I'm stuck with this. >=20 > 7. Deleted all old interface files in '/var/log/vnstat (.green0, .red0, > etc.) >=20 > *Question*: > In my opinion, this could be done after upgrading *plus* a successful > import of the old interface files *plus* a successful start of 'vnstatd > -d --alwaysadd'. If 'vnstatd.db' was successfully created, these files > are not needed anymore. >=20 > How to do this the best way? Should we add a function to the initscript that checks if any files like that= exist and then run a conversion command? That would be safe, even if people restore an older backup. > 8. Since the graphs are no longer updated through 'makegraphs', I > created a symlink in '/etc/fcron.minutely' to '/var/usr/sbin/vnstat' > (*No* parameters, '-u' doesn't exist anymore). Makegraphs does some other things, too. I am not sure if we can remove the sy= mlink, yet. > Now every minute 'vnstat' now grabs the data collected by'vnstatd'. The vnstat call can of course be removed. >=20 > 9. Edited 'traffic.cgi', changed: >=20 > system("/usr/bin/vnstati -c 5 >=20 > To: >=20 > system("/usr/bin/vnstati -c 2 >=20 > This keeps the graphs a bit more "updated". > From 'man vnstat': > '-c (--cache-time) =3D> Update output file only if at least *time* minutes > have passed since the previous file update. I think once a minute is cool too. It does not take a lot to generate those a= nd I think it is valuable that they are recent. > Attachments: > Screenshot fomr my testmachine after importing the old interface files > from my production machine. > I made some minor adjustments to 'vnstat.conf', attached. What are those? -Michael >=20 > Thanks for any help! >=20 > Best, > Matthias >=20 >=20 > --===============0315428615462558419==--