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