Kamailio running out of shared memory (shm)

What you're seeing

ERROR: tm [...]: ... could not allocate shared memory from shm pool
ERROR: dialog [...]: ... no more shm memory
ERROR: tm [...]: t_newtran(): ...

The exact wording varies by module and version. What matters is shm, not pkg. pkg memory is per process and set with -M; shm is the shared pool set with -m. Check how full it is:

kamcmd core.shmmem
kamcmd stats.get_statistics shmem:
kamcmd stats.get_statistics tmx:

If max_used has reached total, you've hit the ceiling at some point. If real_used climbs steadily between restarts at a flat call rate, something is leaking or never being freed.

Likely causes

Most common first.

1. shm is simply too small. The packaged default is 64 MB. That's fine for a lab, but tight for thousands of registrations, dialog tracking, TLS connections and a few busy htables. It's the most common cause and the easiest fix.
2. Transactions pile up during a flood or an outage. Every statefully handled request keeps a transaction in shm until it completes or times out. A scanner flood handled statefully, or a downstream that stops answering INVITEs (held for fr_inv_timer, 120 s by default), can use the whole pool.
3. htables with no expiry. An htable used for bans, counters or caching without autoexpire only grows. Keyed on source IP under attack, it can reach millions of entries.
4. Dialogs that never end. With the dialog module, a call whose BYE never passes through Kamailio stays in memory until default_timeout, 12 hours by default. Missing record_route() or a lost BYE across NAT makes them pile up.
5. A genuine leak. If shm still grows with the causes above ruled out, compare per-module usage over time. Growth isolated to one module often matches a bug already fixed in a later point release.

How to fix

1. Size shm for the load

On Debian/Ubuntu packages the service reads memory sizes from /etc/default/kamailio, in MB:

SHM_MEMORY=512
PKG_MEMORY=16

Restart, not reload. Size for the worst case you've seen plus headroom, and keep an eye on max_used.

2. Keep junk out of the transaction layer

Drop floods and scanners in route[REQINIT] before anything creates a transaction (see blocking scanners). Then shorten how long a dead downstream can hold state:

# milliseconds: time to first reply, and time to final reply once ringing
modparam("tm", "fr_timer", 5000)
modparam("tm", "fr_inv_timer", 60000)

3. Put an expiry on every htable and dialog

# size is the power of two of buckets (8 = 256); autoexpire in seconds
modparam("htable", "htable", "ipban=>size=8;autoexpire=300;")
modparam("htable", "htable", "authfail=>size=8;autoexpire=900;initval=0;")

# no call on this platform lasts longer than 2 hours
modparam("dialog", "default_timeout", 7200)

4. See which module is growing

# per-module shm usage; run a few times, an hour apart
kamcmd mod.stats all shm

# number of active transactions and dialogs
kamcmd stats.get_statistics tmx:active_transactions
kamcmd stats.get_statistics dialog:active_dialogs

Before digging into a suspected leak, move to the latest point release of your series. Many leak fixes only go into point releases.