Gitsync flushes states, as of a few days ago
-
I've noticed that since a few days ago, doing a gitsync (CLI# pfSsh.php playback gitsync RELENG_2_1) seems to kill open states (e.g. I have to restart all my ssh connections everytime I sync to latest webGUI code)
-
Do you have any gateways that are marked as down?
See http://redmine.pfsense.org/issues/3181
-
Either that or some other new change seems to kill states on regular filter reload. I lose SSH connection to pfsense and RDP connection to my home PC when I change a setting that triggers a filter reload.
-
new change seems to kill states on regular filter reload. I lose SSH connection to pfsense and RDP connection to my home PC when I change a setting that triggers a filter reload.
+1
-
I had a system on a 3 Sep snapshot, just updating it now to the latest 4 Sep one that has been tagged as "2.1-RC2". While downloading the update file to my netbook the download kept stopping, and I had to pause continue it. I was making other config changes at the time, so I then made and effort to stop pressing "apply" while the download was running. It still kept stopping. This system has a few site-to-site OpenVPN links coming in to it, and I know they go up and down a lot. So probably there were OpenVPN link transitions happening.
Anyway, I suspect that all states are being cleaned out quite often now, after this commit: https://github.com/pfsense/pfsense/commit/c59dd719e0a6d9ee8deecaa7bff0d6ee8c76e4ca
If that is happening whenever a site-to-site OpenVPN goes up or down, then it will be painful for ordinary users of the main WAN. -
Anyway, I suspect that all states are being cleaned out quite often now, after this commit: https://github.com/pfsense/pfsense/commit/c59dd719e0a6d9ee8deecaa7bff0d6ee8c76e4ca
If that is happening whenever a site-to-site OpenVPN goes up or down, then it will be painful for ordinary users of the main WAN.No OVPN involved here. Simple, every filter reload seems to flush all states. Things such as cron triggered pfBlocker updates, or whatever. Kaboom, disconnected, go to logs, last thing before that is check_reload_status: Reloading filter. Needless to say, this is extremely annoying.
-
Gitsync again, Ermal just pushed a fix, seems some of the logic went missing on the commit to change the behavior. Should be better now.
-
Gitsync again, Ermal just pushed a fix, seems some of the logic went missing on the commit to change the behavior. Should be better now.
Thanks, applied 5aa44e98465dcdb4bde806b5c3cb0a16d30dcb5d and 36fa13a632bad73fb2a8fdc2e9627e3190ea63c6, will watch how's it going.
-
Gitsync again, Ermal just pushed a fix, seems some of the logic went missing on the commit to change the behavior. Should be better now.
Thanks, the issue reported in the first post seems to be fixed now.
-
I have updated 2 systems to a snap including the fix. I just downloaded a 200MB file that took 35 minutes, with both systems in the download path (One on the main WAN links, and a test box sitting behind it, and the client behind that). It ran at full WAN speed and finished perfectly.
Yesterday the download kept stopping and I had to pause/continue it constantly - presumably because of the state killing.
All is well with the world now. -
WFM now, sanity restored. :D
