Bug #4817
closed
rc.start_packages: Restarting/Starting all packages on config sync
0%
Description
Applying configuration of pfsense cause openvpn server restart
When you press apply configuration on DNS TAB or on Traffic Shaper TAB.
OpenVPN Servers disconnect all pears.
I think that this cause all issues
Jul 6 12:12:41 fw1 php-fpm44057: /rc.start_packages: Restarting/Starting all packages.
Jul 6 12:12:40 fw1 check_reload_status: Reloading filter
Jul 6 12:12:40 fw1 php-fpm44057: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.16.10.1 - Restarting packages.
Jul 6 12:12:40 fw1 check_reload_status: Starting packages
Jul 6 12:12:40 fw1 php-fpm44057: /rc.newwanip: rc.newwanip: Info: starting on ovpns3.
Jul 6 12:12:40 fw1 php-fpm44057: /rc.newwanip: rc.newwanip: on (IP address: 172.16.8.1) (interface: []) (real interface: ovpns3).
Jul 6 12:12:40 fw1 check_reload_status: Reloading filter
Jul 6 12:12:40 fw1 php-fpm44057: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.16.8.1 - Restarting packages.
Jul 6 12:12:40 fw1 check_reload_status: Starting packages
Jul 6 12:12:41 fw1 php-fpm44057: /rc.start_packages: Restarting/Starting all packages.
Jul 6 12:12:41 fw1 php-fpm44057: /rc.start_packages: [pfBlockerNG] Sync terminated during boot process.
Jul 6 12:12:42 fw1 php-fpm44057: /rc.start_packages: Restarting/Starting all packages.
Jul 6 12:12:42 fw1 php-fpm44057: /rc.start_packages: [pfBlockerNG] Sync terminated during boot process.
Jul 6 12:16:02 fw1 sshd65266: error: PAM: authentication error for root from 10.10.10.11
Jul 6 12:16:02 fw1 sshd65266: error: PAM: authentication error for root from 10.10.10.11
Jul 6 12:16:05 fw1 sshd65266: Accepted keyboard-interactive/pam for root from 10.10.10.11 port 59227 ssh2
Jul 6 12:25:29 fw1 check_reload_status: Syncing firewall
Jul 6 12:25:29 fw1 check_reload_status: Reloading filter
Jul 6 12:25:31 fw1 php-fpm: /xmlrpc.php: Resyncing OpenVPN instances.
Jul 6 12:25:31 fw1 php-fpm: /xmlrpc.php: Resyncing OpenVPN instances.
Jul 6 12:25:31 fw1 kernel: ovpns1: link state changed to DOWN
Jul 6 12:25:31 fw1 check_reload_status: Reloading filter
Jul 6 12:25:31 fw1 check_reload_status: Reloading filter
Jul 6 12:25:31 fw1 kernel: ovpns1: link state changed to UP
Jul 6 12:25:31 fw1 kernel: ovpns3: link state changed to DOWN
Jul 6 12:25:31 fw1 check_reload_status: rc.newwanip starting ovpns1
Jul 6 12:25:32 fw1 kernel: ovpns3: link state changed to UP
Jul 6 12:25:32 fw1 check_reload_status: rc.newwanip starting ovpns3
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: rc.newwanip: Info: starting on ovpns1.
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: rc.newwanip: on (IP address: 172.16.10.1) (interface: []) (real interface: ovpns1).
Jul 6 12:25:33 fw1 check_reload_status: Reloading filter
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.16.10.1 - Restarting packages.
Jul 6 12:25:33 fw1 check_reload_status: Starting packages
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: rc.newwanip: Info: starting on ovpns3.
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: rc.newwanip: on (IP address: 172.16.8.1) (interface: []) (real interface: ovpns3).
Jul 6 12:25:33 fw1 check_reload_status: Reloading filter
Jul 6 12:25:33 fw1 php-fpm7550: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> 172.16.8.1 - Restarting packages.
Jul 6 12:25:33 fw1 check_reload_status: Starting packages
Jul 6 12:25:34 fw1 php-fpm7550: /rc.start_packages: Restarting/Starting all packages.
Jul 6 12:25:34 fw1 php-fpm7550: /rc.start_packages: [pfBlockerNG] Sync terminated during boot process.
Jul 6 12:25:34 fw1 php-fpm7550: /rc.start_packages: Restarting/Starting all packages.
Jul 6 12:25:34 fw1 php-fpm7550: /rc.start_packages: [pfBlockerNG] Sync terminated during boot process.
Jul 6 12:26:54 fw1 check_reload_status: Syncing firewall
Jul 6 12:26:54 fw1 check_reload_status: Reloading filter
Updated by Chris Buechler almost 9 years ago
- Status changed from New to Feedback
- Affected Version changed from 2.2.3 to All
what packages do you have installed?
That says fw1, but the logs indicate something is config syncing to that system as if it's the secondary in a HA setup. Is something config syncing to that host?
Updated by
Updated by Tsvyatko Kriviradev almost 9 years ago
Hello,
I am sorry for my late response.. It's suck a same...
But I have released I have sync between fw1 and fw2.
fw2 sync config to ---> fw1
But primary Carp cluster and Services are run on fw1.
Then every time when I make change on Carp IP I have disconnections due to this..
Thank you for your support guys.
Updated by Chris Buechler almost 9 years ago
- Subject changed from rc.start_packages: Restarting/Starting all packages time when I press Apply Configuration to rc.start_packages: Restarting/Starting all packages on config sync
- Priority changed from Normal to Low
- Target version deleted (
2.2.4)
this is just how things work currently. That normally doesn't matter because only the system with backup status has the config synced to it. Why are you config syncing from the backup to master system?
Updated by Tsvyatko Kriviradev almost 9 years ago
I had issues with my bgp and carp configurations also some bugs from version 2.2.1 and 2.2.0.
So for couple of weeks we leave backup router as s Primary system and we made changes.
After that we had to synchronize our routers again and we forgot to switch back synchronization from primary bgp carp to backup bgp and carp router.
Updated by Seb A almost 9 years ago
I just discovered the same 'problem', but with a more usual set-up. Sync is from primary to secondary, but secondary is currently master. This is due to an interface being down on the primary, but we have frequent switches even when all interfaces are up.
I was wondering why my load averages were very high, saw CPU usage was at 100%, paniced and started investigating. Starting killing snort instances and disabling them, because restarting them takes a lot of CPU and you do not want to be doing that all the time. I finally found this bug and I can't say I'm too impressed. If this just down to using OpenVPN, because if so I'll remove it! It's not worth it if this is the result. I already had the firewall crash earlier this evening (submitted) so I'm not taking any chances.
Updated by Seb A over 8 years ago
Well to correct my own typo and partly answer my own question therein:
'_Is_ this just down to using OpenVPN, because if so I'll remove it!'
I removed OpenVPN from my secondary and stopped the primary syncing OpenVPN and the secondary no longer restarts all processes. So, my bandwidthd stats are no longer reset. :-) But I still get a CPU spike to 100%, although probably shorter in duration, and I still get this message on the secondary:
php: /xmlrpc.php: Resyncing OpenVPN instances.
Which is weird considering I told the primary not to sync OpenVPN, there is no OpenVPN on the secondary, and the secondary has no sync target. This is on 2.1.5.
I have a lot less logged to the secondary now when I make a change to the primary.
Updated by Chris Buechler about 8 years ago
- Status changed from Feedback to Closed
it's not the config sync, it's the resulting OpenVPN restart that restarts packages. That has a separate ticket