A communications error occurred while attempting XMLRPC sync

jafielding

Hi All,

We're running 2.3.3-RELEASE (amd64) on 2 systems (Master and Backup) and we're seeing the following errors on the Master:

A communications error occurred while attempting Filter sync
A communications error occurred while attempting XMLRPC sync

This is also causing the Backup GUI to become unavailable until SSHing to the box and hitting option 16 to restart PHP-FPM.

I've seen previous posts about this but haven't seen a fix posted.

Any ideas?

Cheers,
Jan

fakircz

Hi,

I ran into this issue yesterday, including the dead Web GUI on the backup system.

~~It seems that the cure is setting the "admin" user as the sync account (the documentation does mention that, but I tried creating a special user account anyway since I don't like using default admin accounts). I still get the error occassionally, but I guess that's because the backup box is significantly slower than the master box and can't keep up (yup, I am aware that it's not recommended).

Edit: It's not entirely fixed, still getting these errors occasionally even if I don't touch anything.~~

Edit: I take it back, it's not fixed at all. The symptoms are exactly as described in post #5.

Regards,
Tom

doktornotor

2.4 can use other accounts rather than admin for XMLRPC.

jafielding

Hi Guys,

Thanks for the responses.

I'm using the admin user to do the sync.

I also tried re-installing the backup box yesterday and starting from scratch and it's still the same :(

Jan

jafielding

It might be worth mentioning that though the Backup box was freshly installed with 2.3.3 yesterday (and then upgraded this morning to 2.3.3-RELEASE-p1) the Master was initially installed with 2.3.0 and then has been upgraded through the Subversions.

I'm thinking of going for a fresh install for the Master with 2.3.3-RELEASE-p1, Sync the config back from the current backup, re-add all the settings that don't sync then swap them back so they sync in the same direction as present. Just to see if a fresh install of the Master makes any difference.

Cheers,
Jan

jafielding

OK - so I re-installed the master with a fresh install to make sure there wasn't an issue that had been picked up while upgrading the through the subversions.
I re-synced the config, added back the missing config that couldn't be synced (VLANS etc.), then switched back the master as the master.

Making any change on the master pushes the change out to the backup but then immediately applies an XMLRPC Lock on the backup and any subsequent changes on the Master fail to sync to the backup.
Eventually the GUI locks up and only restarting PHP-FPM with option 16 on the console removes the lock and restores access to the GUI, until of course any further changes are applied to the Master at which point the whole thing starts again.

So re-installing both boxes didn't make any difference.

I feel like I'm missing something obvious, but as yet don't have a clue what it could be :'(

Any advice would be massively appreciated.

dbottino

Hi all,
i have the same issue.
It seems that the backup gui access dosn't work, and need to restart the php services… (16)

any idea?

aperron2002

Hello everyone,

I am experiencing quite the same thing…
My backup system works fine until... it just doesn't anymore. No GUI access and sync not working. SSH still working.
I haven't been able to identify a pattern yet. Sometimes it takes several minutes, sometimes it goes to the next day.

If I shut down the master unit during the problem, failover takes place and traffic goes on normally.
Of course any new rules and other stuff won't be on the backup.

This is a new installation but I haven't seen that behaviour prior to updating to 2.3.3-p1.

Looks like a bug to me.

Any news on this issue ?

Thanks,

Andre

jafielding

Hi,

I managed to resolve the issue for our case.

The two servers we're using as our pfSense boxes are Dell PowerEdge R210II servers, each came loaded with 2 on board Gigabit Ethernet ports (one being used as the WAN interface and the other for the LAN interface).

In the first instance I had setup the pfSync to use the LAN interface, which I'm led to believe is a big no no, so I then set up a separate VLAN for the pfSync to use, but as this was still using the physical adaptor shared by the LAN interface, it made no difference.

In the end I bought and fitted an additional PCIe Gigabit Ethernet card in each of the servers, set up a VLAN to use the new physical adaptor (not being used by anything else) and set the pfSync to use the new VLAN and since then I have seen no issues with the sync slowing down or the Backup box becoming unresponsive.

Hope this helps.

Cheers,
Jan