Database and Asterisk reload issues: a safe order of operations

Most VICIdial changes touch two moving parts: the database, where settings and call records live, and Asterisk, which actually places the calls. The mistake people make is reloading or restarting one of them at the wrong moment. Get the order right and changes apply cleanly. Get it wrong and you drop live calls for no reason.

Why order matters

When you change a campaign, carrier, or phone in the VICIdial admin, that change lands in the database immediately. It does not become live telephony config until Asterisk is given the new configuration. VICIdial bridges that gap for you: it sets rebuild_conf_files to Y, and the Keepalive process picks the flag up about once a minute, regenerates the affected Conf file, and reloads only what changed. The database write and the Asterisk apply are two steps, and the keepalive is what connects them safely.

The safe order

1. Make the change in the VICIdial admin. This writes to the database and, for managed settings, sets the rebuild flag automatically.
2. Let the keepalive apply it. Wait about a minute. The conf files rebuild and the narrow reload happens on its own, without you touching the command line.
3. Hand-reload only if needed. If you edited a file outside VICIdial's control, or changed something the keepalive does not manage, then reload — the narrowest scope first.
4. Pick a quiet window. Any manual reload, and absolutely any service restart, should happen when few or no agents are dialing.

flowchart TD
  A[Make change in VICIdial admin] --> B[Database updated rebuild flag set]
  B --> C[Keepalive runs about every minute]
  C --> D[Conf files rebuilt narrow reload applied]
  D --> E{Still not applied?}
  E -->|No| F[Done, change is live]
  E -->|Yes, edited a file directly| G[Wait for quiet window]
  G --> H[Hand-reload narrow scope]

What restarting under load costs you

Restarting the database while the dialer is running is the worst version of this. The dialer and the agent screens both depend on the database for every action — pulling the next Lead, writing a Disposition, updating an Agent session. Yank it out from under them and active calls drop, agents freeze, and the Real-time report goes blank or stale. Restarting Asterisk under load is just as bad: it tears down every live Channel at once. Both look like a system-wide outage even though you only meant to apply one setting.

How to tell a change is stuck

• You made an admin change but waited only a few seconds. Give the keepalive a full minute before deciding it did not work.
• The change was to a file VICIdial does not manage, so no rebuild flag was ever set. That genuinely needs a manual reload.
• The keepalive itself is not running. If conf files never rebuild and the Drop rate or dialing pace looks frozen, check that the keepalive process is alive before you start restarting things by hand.

When agents are the ones complaining

If an over-eager reload or restart left agents staring at a stuck screen, the recovery path is the same as any other freeze. Walk through fixing a frozen agent screen before you touch services again, and keep the VICIdial troubleshooting playbook open as your first-response checklist.

A safe reload order is mostly discipline: change, wait, reload only if you must, and never under load. VICIfast runs a managed, hardened VICIdial box with the keepalive and rebuild cycle already tuned, so most changes apply themselves, live in under 40 seconds. See our plans and pricing.