FreeSWITCH 1.11.1 Post-Upgrade SQLite RAM Storage Fix

[pbxgeek]

Please update to the latest commit as of today and run the command below to move SQLite back to RAM storage.

Disclaimer: If you have customized your setup to use PostgreSQL instead of SQLite, you can disregard this notice.

After the upgrade, SQLite was moved to file storage, which is not ideal for performance. Certain features, such as call pickup, may also not work properly when SQLite is stored on disk.

During the FS PBX installation, SQLite is configured to use RAM storage by default. Running the command below will restore the correct configuration.

php artisan fs:migrate-sqlite-to-ram

After running the command, please flush the cache first, then restart FreeSWITCH for the change to take effect.

To verify that FreeSWITCH uses the correct path for database storage, you can run this command:

 sudo lsof -nP -p "$(pidof freeswitch)" \
  | grep -E '/dev/shm/.*\.db|/var/lib/freeswitch/db/.*\.db'

The output should look like this

freeswitc 668409 www-data    6u      REG               0,24   385024     138290 /dev/shm/core.db
freeswitc 668409 www-data   11u      REG               0,24   339968          4 /dev/shm/sofia_reg_external.db
freeswitc 668409 www-data   22u      REG               0,24   352256         84 /dev/shm/sofia_reg_internal.db
freeswitc 668409 www-data   31u      REG               0,24   339968          4 /dev/shm/sofia_reg_external.db
freeswitc 668409 www-data   32u      REG               0,24   352256         84 /dev/shm/sofia_reg_internal.db
freeswitc 668409 www-data   34u      REG               0,24    16384        164 /dev/shm/callcenter.db
freeswitc 668409 www-data   36u      REG               0,24    16384     138295 /dev/shm/fifo.db

All directories should point at /dev/shm

 

[ou812]

I also have double outputs even after server reboot.

freeswitc 846 www-data 5u REG 0,25 409600 2 /dev/shm/core.db
freeswitc 846 www-data 6u REG 0,25 409600 2 /dev/shm/core.db
freeswitc 846 www-data 10u REG 0,25 339968 4 /dev/shm/sofia_reg_external.db
freeswitc 846 www-data 20u REG 0,25 339968 86 /dev/shm/sofia_reg_external-ipv6.db
freeswitc 846 www-data 27u REG 0,25 339968 4 /dev/shm/sofia_reg_external.db
freeswitc 846 www-data 32u REG 0,25 929792 166 /dev/shm/sofia_reg_internal.db
freeswitc 846 www-data 40u REG 0,25 339968 86 /dev/shm/sofia_reg_external-ipv6.db
freeswitc 846 www-data 44u REG 0,25 339968 246 /dev/shm/sofia_reg_internal-ipv6.db
freeswitc 846 www-data 50u REG 0,25 929792 166 /dev/shm/sofia_reg_internal.db
freeswitc 846 www-data 52u REG 0,25 339968 246 /dev/shm/sofia_reg_internal-ipv6.db
freeswitc 846 www-data 54u REG 0,25 16384 445 /dev/shm/callcenter.db
freeswitc 846 www-data 56u REG 0,25 16384 491 /dev/shm/fifo.db
freeswitc 846 www-data 76u REG 0,25 929792 166 /dev/shm/sofia_reg_internal.db

 

[kenn10]

I rebooted the server to clear the issue. I think I failed to clear the cache and then ran it again and caused the double.

 

[ou812]

I cleared the cache using the gui (Status-Sip Status-Flush Cache) then restarted freeswitch. Hopefully this won't cause issues.

 

[pbxgeek]

I rebooted the server to clear the issue. I think I failed to clear the cache and then ran it again and caused the double.

This is normal. lsof lists open file descriptors, not unique database files.

All entries use the same FreeSWITCH PID (846), and repeated paths share the same inode. For example, both core.db entries use inode 2. This means one database file is opened through multiple SQLite connections—not multiple database copies.

A reboot simply recreates those connections. It’s only concerning if:

• Different FreeSWITCH PIDs open the same database.
• Databases are simultaneously open under both /dev/shm and /var/lib/freeswitch/db

Your output confirms the databases are correctly running from RAM.

 

[dbz195]

Just to confirm, this only applies to users who have updated FS to 1.11.1 but not FSPBX 1.9.x?
or both?