> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > I'm wondering about the "core restart now" leaving all that memory and 
> > threadpool threads active.  Won't those things still be around after the 
> > restart?  A "core stop now" is no problem because the system will reclaim 
> > everything anyway.  However, a restart may just accumulate the lost 
> > resources.

>From http://man7.org/linux/man-pages/man2/execve.2.html:
       execve() does not return on success, and the text, data, bss, and
       stack of the calling process are overwritten by that of the program
       loaded.

My understanding is that execvp() is a front-end procedure that uses execve 
(that's what my local man-pages says).  This tells me that the memory is not an 
issue for sure.  Since it's a new process and all memory is purged, I don't see 
how threads could be maintained.  If this is an issue then my change makes it 
only slightly worse.  Channels drivers all have a monitoring thread and they 
are already left for the OS to cleanup during "core restart now".


> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > /branches/13/main/bridge.c, lines 5356-5357
> > <https://reviewboard.asterisk.org/r/4501/diff/1/?file=72402#file72402line5356>
> >
> >     These can be merged.

Will do.


> On March 20, 2015, 8:21 p.m., rmudgett wrote:
> > /branches/13/main/http.c, line 2341
> > <https://reviewboard.asterisk.org/r/4501/diff/1/?file=72417#file72417line2341>
> >
> >     This may need to stay.  HTTP needs to shutdown socket connections.
> >     
> >     Manager as well.

I don't think this is an issue, asterisk.c sets FD_CLOEXEC to FD's 3..32768 in 
the final stage of restart.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4501/#review14759
-----------------------------------------------------------


On March 15, 2015, 6:33 a.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4501/
> -----------------------------------------------------------
> 
> (Updated March 15, 2015, 6:33 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24142, ASTERISK-24683, ASTERISK-24805, and ASTERISK-24881
>     https://issues.asterisk.org/jira/browse/ASTERISK-24142
>     https://issues.asterisk.org/jira/browse/ASTERISK-24683
>     https://issues.asterisk.org/jira/browse/ASTERISK-24805
>     https://issues.asterisk.org/jira/browse/ASTERISK-24881
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> We've had many issues related to "core stop now" or "core restart now" 
> causing segmentation faults.  The solution to this is to change almost 
> everything to use ast_register_cleanup.
> 
> Exceptions:
> CDR: Flush records.
> res_musiconhold: Kill external applications.
> AstDB: Close the DB.
> canary_exit: Kill canary process.
> 
> Although some changes from ast_register_atexit to ast_register_cleanup are 
> not strictly necessary, the point is for nothing to use ast_register_atexit 
> except where required.  For this reason the change is across the board.
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/xmldoc.c 432991 
>   /branches/13/main/utils.c 432991 
>   /branches/13/main/udptl.c 432991 
>   /branches/13/main/timing.c 432991 
>   /branches/13/main/threadstorage.c 432991 
>   /branches/13/main/taskprocessor.c 432991 
>   /branches/13/main/stun.c 432991 
>   /branches/13/main/stasis.c 432991 
>   /branches/13/main/sounds_index.c 432991 
>   /branches/13/main/sorcery.c 432991 
>   /branches/13/main/rtp_engine.c 432991 
>   /branches/13/main/pickup.c 432991 
>   /branches/13/main/pbx.c 432991 
>   /branches/13/main/message.c 432991 
>   /branches/13/main/manager_system.c 432991 
>   /branches/13/main/manager_mwi.c 432991 
>   /branches/13/main/manager_endpoints.c 432991 
>   /branches/13/main/manager_channels.c 432991 
>   /branches/13/main/manager_bridges.c 432991 
>   /branches/13/main/manager.c 432991 
>   /branches/13/main/indications.c 432991 
>   /branches/13/main/image.c 432991 
>   /branches/13/main/http.c 432991 
>   /branches/13/main/format_cache.c 432991 
>   /branches/13/main/format.c 432991 
>   /branches/13/main/file.c 432991 
>   /branches/13/main/features.c 432991 
>   /branches/13/main/dnsmgr.c 432991 
>   /branches/13/main/data.c 432991 
>   /branches/13/main/core_local.c 432991 
>   /branches/13/main/config_options.c 432991 
>   /branches/13/main/config.c 432991 
>   /branches/13/main/codec.c 432991 
>   /branches/13/main/cli.c 432991 
>   /branches/13/main/channel.c 432991 
>   /branches/13/main/cel.c 432991 
>   /branches/13/main/ccss.c 432991 
>   /branches/13/main/bridge.c 432991 
>   /branches/13/main/astobj2_container.c 432991 
>   /branches/13/main/astobj2.c 432991 
>   /branches/13/main/astmm.c 432991 
>   /branches/13/main/astfd.c 432991 
>   /branches/13/main/asterisk.c 432991 
>   /branches/13/main/aoc.c 432991 
>   /branches/13/include/asterisk.h 432991 
> 
> Diff: https://reviewboard.asterisk.org/r/4501/diff/
> 
> 
> Testing
> -------
> 
> Compiled, started and ran 'core stop now'.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to