I’m starting pmacctd from command line as a daemon, using
pmacctd -f /etc/pmacct/ -D
The daemon runs of course but I noticed that every day at 1:25 it shuts down itself and does not restart any more. I’m using pmacct/d for testing purposes for quite a few days, however, each night it stops and does not restart.
IPFire log tells nothing about the cause, ok some lines are added to /var/log/messages, I cannot add them at the moment, will do when at home again, but nevertheless, the logs indicate no error or similar at this point of time, neither from pmacct nor from IPFire.
As already told, it is strange that this happen each day now at the very same time. IPFire of course does not shut down nor does it loose its internet connection or toe the switch/LAN or runs low on memory this time (I’m monitoring this, too, and can say this for sure)
Nov 10 01:24:04 ipfire pakfire: PAKFIRE INFO: IPFire Pakfire 2.23-x86_64 started!
Nov 10 01:24:04 ipfire pakfire: CORE INFO: core-list.db is 2399 seconds old. - DEBUG: noforce
Nov 10 01:25:07 ipfire pmacctd[11359]: WARN ( default/core ): connection lost to ‘green_ports-memory’; closing connection.
Nov 10 01:25:08 ipfire pmacctd[11359]: WARN ( default/core ): connection lost to ‘green_basic-memory’; closing connection.
Nov 10 01:25:09 ipfire pmacctd[11359]: WARN ( default/core ): connection lost to ‘green_full-memory’; closing connection.
Nov 10 01:25:09 ipfire pmacctd[11359]: WARN ( default/core ): no more plugins active. Shutting down.
Nov 10 01:25:09 ipfire kernel: device green0 left promiscuous mode
Nov 10 01:25:11 ipfire pmacct: GeoIP database has been updated
Nov 10 01:25:13 ipfire pakfire: PAKFIRE INFO: IPFire Pakfire 2.23-x86_64 started!
What’s interesting, I’m logging the output of pmacct print plugin from within a Python script and just saw that the appropriate CSV-file was still process at the moment when pmacctd shut down:
I’ve now set up a cron job to restart pmacctd at 1:28 o’clock. Guess this will work, however I rather would like to know the source of the shutdown.
I’ve found an option (plugin_exit_any) in pmacct Wiki which might solve this, but reading the description, I feel that the opposite will hapen, if I set it to true.
Hence, I added the option to my config but I explicitely set the value to false which is the default value, btw. But one never knows…
Hi Michael,
is there somewhere a segfault via dmesg findable ? Have found here also some problems with the print plugin in 1.7.3er version. Is 1:25 not also fcron time ?
nothing special here on my side, using dmesg | grep segfault does not return a single line, if I correctly used this command.
Cron job? Cron log is disabled for some good reasons (too many log entries) and I could not find a single line in cron tab that points exactly to 1:25h.
Same here, as posted above from my logs. Where is this job configured? crontab does not list it. Is it burried somewhere ind the /etc/fcron.xxx subfolders?
Edit: Found! /etc/fcron.daily. But this means that cron is executing the jobs in this subfolder each day at 1:25? Can I temporarly disable the GeoIP updater?
Edit2: Yes, according to this line in crontab: &nice(10),bootrun 25 1 * * * test -x /usr/local/bin/run-parts && /usr/local/bin/run-parts /etc/fcron.daily
So still the question: can I disable the GeoIP updater without deleting it from the folder?
So far I did not remove the cron job, however, I restart pmacct at 1:28 and this worked today.
It seems it is somehow related to the GeoIp updater, isn’t it?
You can check it by executing the geoip-updater manually. If pmacctd runs, you can execute the script with enabled debugger via bash -x /etc/fcron.daily/geoip-updater
if Pmacct runs before (ps aux) and after executing the updater the problem should not be caused by the script in my opinion.
Found the source of the issue by executing the updater manually:
+ /etc/init.d/pmacct restart
Stopping the pmacct daemon… [ OK ]
Starting the pmacct daemon…
ERROR: [/etc/pmacct/pmacct.conf] file not found. [ FAIL ]
The init script tries to restart with config-file pmacct.conf. Mine, however, is named different. So the daemon won’t start in this case. Now, I’ve two options: rename my configuration file or change the init script.
The first one is not that easy since I will monitor green and red interface later, right now just the green one, and using the mapping file I cannot properly distinguish between both interfaces.
Anyway, when using two config files later on, I guess I will have to change the init script anyway to start two pmacctd daemons at once.
Or do you know how to bring the interface name and not the index from the mapping file into the aggregation filter and into the resulting CSV-file?
The numeric index for the interface ssems to be possible, but I don’t know if this is true also for the interface name, like green.
this has also been a problem with a newer build since i wanted to norm the directory names to ‘pmacctd’ which is here fixed in my env but which should be another thing. OK, so the first suspect with fcron was indeed the problem… We should find really a way to mark such stuff in one topic as solved !
Why you want to use two Core instances ? Isn´t it possible to solve this via two or multiple plugins in one configuration and therefore with only one Core process ?
