"check_reload_status: syncing firewall" every 5 minutes in log
-
Ok, I sent the "/etc/rc.savevoucher" command to the pfSense box through "Execute Shell Command" field - but since then the system's been unresponsive (five minutes). Are you sure that was a good idea? :)
I am awaiting a desperate call from my employer any minute… -
I'm using vouchers too.
I executed the command via ssh and it worked as jimp said.
The message appeares in the log. -
I'm running captive portal and vouchers and I see those messages in the system log:
clog /var/log/system.log | grep syncing | more
May 28 18:38:38 pfsense2 check_reload_status: syncing firewall
May 28 18:43:42 pfsense2 check_reload_status: syncing firewall
May 28 18:48:45 pfsense2 check_reload_status: syncing firewall
May 28 18:53:48 pfsense2 check_reload_status: syncing firewall
May 28 18:58:51 pfsense2 check_reload_status: syncing firewall
May 28 19:03:55 pfsense2 check_reload_status: syncing firewall
May 28 19:08:59 pfsense2 check_reload_status: syncing firewall
May 28 19:14:02 pfsense2 check_reload_status: syncing firewall
May 28 19:19:06 pfsense2 check_reload_status: syncing firewall
May 28 19:24:09 pfsense2 check_reload_status: syncing firewall
May 28 19:29:13 pfsense2 check_reload_status: syncing firewall
May 28 19:34:15 pfsense2 check_reload_status: syncing firewall
May 28 19:39:19 pfsense2 check_reload_status: syncing firewall
May 28 19:44:22 pfsense2 check_reload_status: syncing firewall
May 28 19:49:25 pfsense2 check_reload_status: syncing firewall
May 28 19:54:28 pfsense2 check_reload_status: syncing firewall
May 28 19:59:32 pfsense2 check_reload_status: syncing firewall
May 28 20:04:35 pfsense2 check_reload_status: syncing firewall
May 28 20:09:38 pfsense2 check_reload_status: syncing firewall
May 28 20:14:42 pfsense2 check_reload_status: syncing firewall
May 28 20:19:46 pfsense2 check_reload_status: syncing firewall
May 28 20:24:49 pfsense2 check_reload_status: syncing firewall
May 28 20:29:52 pfsense2 check_reload_status: syncing firewall
May 28 20:34:55 pfsense2 check_reload_status: syncing firewall
May 28 20:39:58 pfsense2 check_reload_status: syncing firewall
May 28 20:45:01 pfsense2 check_reload_status: syncing firewall
May 28 20:50:04 pfsense2 check_reload_status: syncing firewall
May 28 20:55:08 pfsense2 check_reload_status: syncing firewall
May 28 21:00:11 pfsense2 check_reload_status: syncing firewall
. . .On my other pfSense system where I'm not running captive portal:
clog /var/log/system.log | grep syncing | more
uname -a
FreeBSD pfsense.example.org 8.1-RELEASE-p3 FreeBSD 8.1-RELEASE-p3 #1: Sat May 21 21:30:20 EDT 2011 sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.8 i386
uptime
11:09PM up 8 days, 14:54, 2 users, load averages: 0.15, 0.10, 0.07
I'm running the same pfSense build on both systems.
-
So mystery solved. It's the voucher saving process every five minutes causing the log message.
It's also writing out the config every five minutes in that case, too, so I imagine that your backup history under Diagnostics > Backup/Restore is quite useless.
-
Jimp,
you are right. The Config History also tells every 5 minutes: (system): made unknown change
Thanks for helping.
-
Well, does that mean something for devs? Do you consider that bug? May we look forward to this to be fixed in the post-RC version? :)
-
If you enable the voucher save feature, it will always happen. You can change how often this happens in the voucher config options.
Without saving the vouchers periodically, a sudden reboot would lose voucher usage data.
-
jimp,
the text in the gui tells: 'No save is done if no new vouchers have been activated.'
There are no new vouchers or active vouchers.
-
I don't see any checks to prevent that write in the backend code. The function called writes the db out whenever it's called. Perhaps that was intended to be added later.
https://github.com/bsdperimeter/pfsense/blob/master/etc/inc/voucher.inc#L622
-
Maybe. But right now we consider this a little bug, right? So I created a new issue in Redmine. Thank you guys for your cooperation. :)
-
I can confirm, that since I'm using built Sat Jun 11 the bug is corrected and there are no more log entries and the history is no longer flooded.
There is also no more possibility to adjust the time of storing to database. I assume, it's still done all 5 minutes, but now silencely.
