[SR-Users] Best place to change mem settings

Daniel Tryba d.tryba at pocos.nl
Thu Jan 3 22:05:27 CET 2019


On Thu, Jan 03, 2019 at 07:06:51PM +0000, Duarte Rocha wrote:
> As far as i can tell, i have 3 ways to permanently change the memory
> settings in Kamailio :
> 
> /etc/init.d/kamailio , /etc/default/kamailio and src/core/config.h.
> 
> What's the priority between them? If i have different values in all 3 of
> them, which one will be used? Which is one is the best to use reliably?
> 
> I recently upgraded my Kamailio from 5.0 to 5.2 and i need 12Mb of PKG.
> Before starting the new version for the first time i changed the values in
> /etc/default and the memory error didn't go away. It only worked after i
> changed it in core/config.h and recompilled. After that, i started Kamailio
> and i could do the changes in /etc/default without any problem. Does this
> happen for a reason?

You should look into what your platform does these days. Linux distros
infected with systemd don't work the same way they did the last 2x
years. Looking at how Debian does things (tm):
- /etc/init.d/kamailio that script will not be executed anymore, there
  are systemd binding at the top (". /lib/lsb/init-functions") that will
  detect there is systemd magic and will use that instead. You can
  disable this by setting a certain variable (you'll have to search
  that somewhere). 5.0 might not have had this functionality in the
  init.d file, 5.1.x has, so I guess 5.2 also has.
- /etc/default/kamailio included from /etc/init.d/kamailio (but see
  above) and from the systemd magic stuff (see output of "systemctl cat
  kamailio.service"), but if you are trying get coredump you see the
  variable from the default file isn't used anywhere (and as such
  setting DUMP_CORE=yes doesn't do anything anymore (spoiler: set
  "LimitCORE=unlimited" in a "[Service]" section with systemctl edit
  kamailio.service))
- src/core/config.h compile time hardcoded, not a very good option to
  change anything runtime.

If you use any other distro, checkout what that does these days.
Yesterdays knowledge is useless with systemd.

BTW you might not have read it between the lines: I hate systemd.
Almost everything that broke in the last couple of years can be traced
back to systemd (sure it fixed a few things and appears to be reasonable
stable these days, but you can only get one first impression and systemd
fucked it up bigtime for me).



More information about the sr-users mailing list