<div dir="ltr">Ok thank you so much for all advice<br><br>
<div class="gmail_quote">2011/5/20 A J Stiles <span dir="ltr"><<a href="mailto:asterisk_list@earthshod.co.uk">asterisk_list@earthshod.co.uk</a>></span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Friday 20 May 2011, Dovid Bender wrote:<br>> I had issue with call files. They would lock up the system (this was 5<br>> years ago so maybe things have changed.....)<br><br></div>Whenever you open a file for writing, a link is created in the containing<br>
folder's directory (which says where on the disk the file is located)<br>pretty much straight away -- so other processes can see the file. And files<br>are written to disk, not one character at a time, but in blocks whose size<br>
depends on the filesystem, one full block at a time. The last block may well<br>be incomplete, and so contain junk after the file proper; but the directory<br>entry gives the actual file size, so the junk can be ignored.#<br>
<br>This creates a race condition: Asterisk may try to parse a call file which is<br>still in an incomplete state (empty or just the first block of several),<br>and get its knickers in a twist.<br><br>The *proper* way to avoid this situation, is to create the call file in a<br>
temporary location first; then `mv` it to the /var/spool/asterisk/outgoing/<br>folder. Moving a file within a filesystem just entails putting a new link in<br>the destination folder's directory, and removing the one from the old<br>
directory. Moving a file across filesystems entails a copy operation; but<br>either way, the important thing is that *the link to the destination file<br>won't be placed in the folder's directory until the data is actually there*.<br>
<br>The *bodgy* way to avoid this situation, is to make sure the file is smaller<br>than one logical block on the filesystem where .../outgoing/ resides; turn<br>off buffer autoflushing in the scripting language; and cross your fingers<br>
that the file will already be complete in the cache when the directory is<br>updated. And even if it works on your system today, you might find that an<br>upgrade to Asterisk, your scripting language, whatever invoked the script,<br>
the filesystem driver in the kernel, or even a change in RAM or disk usage on<br>your server, breaks it tomorrow.<br><font color="#888888"><br>--<br>AJS<br><br>Answers come *after* questions.<br></font>
<div>
<div></div>
<div class="h5"><br>--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com/" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br> <a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></div></div></blockquote></div><br></div>