Summary:	ASTERISK-24496: Asterisk random crash: when /var/lib/asterisk/sounds/ is mapped to windows share
Reporter:	Conrad de Wet (Conrad)	Labels:
Date Opened:	2014-11-05 08:05:28.000-0600	Date Closed:	2014-11-06 08:57:15.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	1.8.31.0	Frequency of Occurrence	Occasional
Related Issues:
Environment:	Centos with mounted network share 1000Mb network	Attachments:
Description:	We have all our asterisk servers mapped to the same network share - this makes it great to manage one place for all asterisk sounds, greetings, music on hold etc etc. It even allows us to swap clients on boxes without having to carry over all the sound files (using database for everything else). Yesterday the one box processed 140,000 minutes of call - mostly using queues - with the shared music folder - not one single problem. Today, at 2:00 suddenly a segfault. No changes to the system at all. There appears to be a bug in the way Asterisk handles moh files for queues when the source folder is mapped to a network share. It creates a segfault.... randomly. I have not back traced the crash dump, because it will show me what it showed me last time - it crashed in the queue playing back a stream. (We cannot add any more debugging tools.) Please could someone test this scenario. It's extremely useful to have all the sound files in one place. But its so very random in its crash - tho it does appear to be when high call volumes. (Other boxes doing very little have never crashed like this.) I know i'm not being terribly helpful here - but if someone else wants the same as me - to have a central location for all sounds files - then please help with this one.
Comments:	By: Matt Jordan (mjordan) 2014-11-05 08:54:13.045-0600 Thank you for your bug report. In order to move your issue forward, we require a backtrace[1] from the core file produced after the crash. Also, be sure you have DONT_OPTIMIZE enabled in menuselect within the Compiler Flags section, then: make install After enabling, reproduce the crash, and then execute the backtrace[1] instructions. When complete, attach that file to this issue report. [1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace By: Conrad de Wet (Conrad) 2014-11-06 08:33:18.617-0600 Thanks, we are unlikely to re-compile our production server with DONT_OPTIMIZE. That being said, this is likely to be more of a conceptual issue - tricking asterisk to think that a folder is local to the disk may not have been the best idea. If anyone else comes across this we implemented a fanatic fix for this that's working perfectly: Previously we mounted the network share to /var/lib/asterisk/sounds/ but this is not necessary, and appears to cause issues that im sure the community are not interested in fixing - but it doesn't have to map to this folder. What we did was mount the network share to say /var/lib/asterisk/sounds-src and used rsync to keep the actual sounds folder synced. This works perfectly! Just run a cron Job every 2 min or what ever: rsync -a --delete /var/lib/asterisk/sounds-src/ /var/lib/asterisk/sounds/ And your sounds folder is kept perfectly up to date. The best thing about this solution is that the file server can even go down, or be rebooted, and asterisk keeps running as per normal - then when its back, and the mount restores, the sync can carry on as before. The --delete option is useful but not mandatory - it will remove file that have been removed from the source folder. Apparently they are working on something is Asterisk 13, to do with http getting the sounds file, and caching it. This of course means hosting all your sounds but also means that you don't have to have the copy on the disk of each box - could be a great space saver. Well, for now ill just stick to my own solution - seems neat and works well! Thanks Matt By: Matt Jordan (mjordan) 2014-11-06 08:57:49.833-0600 If you're not able to provide a backtrace, that unfortunately there isn't anything else we can do. If this does end up being more of a persistent problem and you're able to get the information we need to diagnose it, please let us know by commenting on this issue or in #asterisk-bugs and we'll be happy to re-open the issue.