Bug #7469

local_sync_accounts() slowness can trigger GUI/XMLRPC failures with many accounts

Added by Jim Pingle 11 months ago. Updated about 1 month ago.

User manager
Target version:
Start date:
Due date:
% Done:


Affected Version:
Affected Architecture:


When a firewall has many local accounts, the time it takes for local_sync_accounts() to finish grows large enough to trigger timeouts and other problems for XMLRPC.

Notably, in an HA cluster this becomes a burden because that function is called for each filter sync.

On stand-alone firewalls the function is only called during bootup, so it does not have quite the same impact in that scenario, though it still delays the boot process.

To illustrate the issue I made a playback script that calls local_sync_accounts() and nothing else:

: grep -c '<user>' /conf/config.xml 
: time pfSsh.php playback localsyncusers
1.379u 5.649s 1:17.53 9.0%    633+216k 0+16190io 0pf+0w

For 44 accounts this particular test firewall needed 1 min 17 seconds to complete the sync process. This could easily overrun PHP/XMLRPC timeouts depending on the speed of the firewall cpu/disks/etc.

We have at least one customer hitting the issue ( 16693 ), plus at least one user report ( )

Associated revisions

Revision 79f7bc7f
Added by Renato Botelho about 1 month ago

Fix #7469

  • Rename local_sync_accounts() to local_reset_accounts() and keep it
    only being used /etc/rc.bootup
  • Reimplement local_sync_accounts() receiving a list of users and
    groups to be added and/or deleted
  • Remove call to filter_configure xmlrpc method from
    rc.filter_synchronize since it's now called internally from
  • On restore_config_section implementation stop copying all content
    from user/group sections. Instead check for new/modified/deleted
    items and create necessary arrays to be passed to local_syng_accounts
  • Add a parameter to filter_configure xmlrpc method to decide when to
    call a full reset of users/groups using local_reset_accounts()

Revision dc3bc1f8
Added by Renato Botelho about 1 month ago

Fix #7469

Sort users / groups alphabetically on config.xml


#1 Updated by Renato Botelho 11 months ago

  • Target version changed from 2.4.0 to 2.4.1

Pushing to 2.4.1 because the whole function should be changed to be optimized

#2 Updated by Jim Pingle 5 months ago

  • Target version changed from 2.4.1 to 2.4.2

Moving target to 2.4.2 as we need 2.4.1 sooner than anticipated.

#3 Updated by Renato Botelho 4 months ago

  • Target version changed from 2.4.2 to 2.4.3

#4 Updated by Renato Botelho about 1 month ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#5 Updated by Jim Pingle about 1 month ago

  • Status changed from Feedback to Assigned

Current code is better but is not putting the users back into matching order on both units. Renato is working on an improvement to preserve the order on all nodes.

#6 Updated by Renato Botelho about 1 month ago

  • Status changed from Assigned to Feedback

#7 Updated by Paighton Bisconer about 1 month ago

Tested on Current Base System 2.4.3.a.20180216.1415

Syncing 106 users and adding a 107th took maybe two seconds, new user was there when secondary users page was reloaded immediately after saving new user.

#8 Updated by Renato Botelho about 1 month ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF