Hello,
based on many reports coming over along all the past years, there are
crashes that happen on module destroy callbacks, many could be fixed,
but some cannot be predicted, depending on the moment when the kill
(shut down) is triggered.
Furthermore, there are cases when the clean makes no much sense, like
attempting to close the DB connection, because the destroy callback is
executed by Kamailio's main process only, which does not handle SIP
traffic and usually does not have DB connection,. So actually, all the
other connections from the SIP works are clean up automatically by the
OS on process shut down.
Also, the pkg and shm blocks are cleaned up as a whole after all,
therefore trying to free chunks inside them that were used by various
internal structures is kind of waste of time. The main purpose to do it
in the past it to be able to discover memory leaks by having status
reports written in syslog, but these reports can be triggered by RPC
during runtime and it is even better to get them in such way.
I think that the best is to use module destroy callbacks only to save
data to backend (e.g., database) that has to be reloaded on restart, and
leave the memory/resources clean up to the OS. In this way we also deal
nicer with the inter-modules dependencies, the structures of a module
will be always available, even after its mod-destroy callback execution,
so if another module depending on them still wants to access, it should
be no problem.
At the last Kamailio Devel meeting we had a brief discussion that we may
want to change mod-destroy to be done in two steps, first for storing
meeded data to backed and then do the cleanup, but I think it is better
without the 2nd step.
Any comments or other suggestions?
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3868
-- Commit Summary --
* Revert "ims_registrar_pcscf: update registered state to pending registration if contact exists"
* ims_registrar_pcscf: fix typo in comments
* ims_ipsec_pcscf: update security params of newly created ipsec tunnel in contact
-- File Changes --
M src/modules/ims_ipsec_pcscf/cmd.c (12)
M src/modules/ims_registrar_pcscf/save.c (13)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3868.patchhttps://github.com/kamailio/kamailio/pull/3868.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3868
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3868(a)github.com>
Hey Team,
I submitted a PR a while back that has not had much discussion:
https://github.com/kamailio/kamailio/pull/3828
The intention was to allow loading in unsigned integer IDs from DB into PVs.
Currently converting unsigned integers from DB to PVs will error by
default unless the module specifically handles the ease use case.
When the following parameter is enabled the srdb interface will allow
the conversion to an integer PV value (possibly overflowing):
|modparam("db_mysql", "unsigned_type", 1) |
This PR allows the srdb APIs to convert the unsigned integer to an
unsigned integer PV value.
This can be quite useful in modules such as |auth_db| / |permissions|
that can load an arbitrary column into a PV (|load_credentials|,
|tag_col|/|peer_tag_avp|, etc..).
Since most ID columns are auto incrementing unsigned integers this just
makes sense for referring to customer data.
Elevator pitch over..
What I need help with is reviewing the srdb changes, since I am unsure
what side effects that would have on other modules.
Comments are welcome here, on the PR, or find me on the matrix channel
(@devopsec).
Happy Coding..
Regards,
Tyler Moore
Full Stack Software Engineer
dOpenSource