[asterisk-bugs] [JIRA] (ASTERISK-28567) Problem with ASTERISK-20207: Asterisk should clear out any .lock files in the voice mail directory on startup.

[George Joseph (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Joseph updated ASTERISK-28567:
-------------------------------------

    Summary: Problem with ASTERISK-20207: Asterisk should clear out any .lock files in the voice mail directory on startup.  (was: CLONE - problem with ASTERISK-20207: Asterisk should clear out any .lock files in the voice mail directory on startup.)

> Problem with ASTERISK-20207: Asterisk should clear out any .lock files in the voice mail directory on startup.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28567
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28567
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Applications/app_voicemail
>    Affects Versions: 13.28.0, 16.5.0
>         Environment: debian9 realtime odbc mysql
>            Reporter: Michael
>      Target Release: 13.27.0, 16.4.0, 17.0.0
>
>
> While attempting upgrade from vcertified-13 to v13.28.1 or to v16.5.1, asterisk takes a really long time to start.  It stops after loading app_voicemail.  No logging or debug indicates what is wrong.  While strace'ing the pid, i see asterisk is traversing the voicemail directory.  This lead me to ASTERISK-20207.  Clear out any lock files on startup.  This probably works fine with a small amount of mailboxes, but with 7,500+ mailboxes, it takes up to 30 minutes to start.
> after commenting out the call in :
> static int load_module(void)
> ...
>         /* Now that we have a spool directory, clean up old lock files */
>         /* cleanup_orphaned_lock_files(VM_SPOOL_DIR); */
> ...
> and recompiling, asterisk starts up right away.



--
This message was sent by Atlassian JIRA
(v6.2#6252)