tmpfs gets filled under versions 2.4-3XX onwards

[boybawang]

Hi guys,

I have this observation to share, I have boxes updated to 2.4-3xx svn versions, all of them have encountered tmpfs being filled up with recordings, i still have a few versions running 2.4-2XX versions and lower and they are not having that kind of problem.

Here is my OS: 21 servers Ubuntu Server 10.04 x64 with 2.4-3XX upto latest build which is 2.4-324a i believe
10 servers Ubuntu Server 10.04 x64 with 2.4-2XX version and lower

Those 21 servers are experiencing tmpfs being filled up from time to time and I need to reboot in order to clear tmpfs, I also am checking weather or not its an OS problem and doing further observation.

[williamconley]

Are you talking about the temp file system set up for asterisk/monitor before asterisk/monitorDONE?

IF so, this is handled by the installer (the location and size of that temp file). Which means ... you should try to find and mimic the setup from Vicibox, as we've not had that problem ONCE.

[boybawang]

its by default using tmpfs as documented in the scratch install

/etc/fstab

tmpfs /var/spool/asterisk/monitor tmpfs rw 0 0

this is what ive been using always in any OS, so far in my observation those with newer versions i mentioned get tmpfs at 100% , it either mean they maybe have ram problems or could be something else

[williamconley]

that's nice. but i wasn't talking about the scratch install. i was talking about vicibox

Vicibox 3.X.X (and even 1.0.0!) do not seem to exhibit this problem. Perhaps you should check that method and see if it is the same/similar or different than the setup you are talking about. If it is different ... your problem could be solved instantly (and may never have occurred if you had used vicibox)

[boybawang]

the implementation of vicibox still uses tmpfs on fstab, its just the same i checked, im going to check both the recording scripts and compare just to make sure, this is the first time this happened, those previous versions i have below 2.4-3XX dont exhibit that problem from time to time, those above 2.4-311a had that problem all of them, dont show your arrogance by using the exclamation point since im not deaf anyway nor am i crosseyed

[randy_delgado_03]

@boybawang

I ran into this kind of prob in my current version(see signature).

What i did was i unmounted the /var/spool/asterisk/monitor from tmpfs and let it dump the temporary recordings on the hard disk and since then i had no probs ...

The only drawback i ran into this setup is the joining of in and out recs is kinda slow.

Pero tolerable naman pre (^_^)

Best of luck ...

[williamconley]

And the Size of this temp filesystem? (compared between the two install types)

[boybawang]

i was trying to compare and i found out that versions above 2.4-3XX experienced this problems all 21 stand alone servers that I recently upgraded for a client, and yes i just disabled the use of tmpfs till i get to figure out what went wrong, I will run through the mix codes tonight or the day after tomorrow to double check, because both 21 stand alone servers had no modifications all stock with same fstab entries and were working fine before before update to latest svn, but again i may be wrong at the cost of 21 servers

[williamconley]

Cuz I'm looking at a stock system with a 2G tmpfs for asterisk/monitor and a premium system with 4G tmpfs for asterisk/monitor.cron

Also: newer crontab entries have:

Code: Select all

#0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl --MIX
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl

Note the fist line "commented out" and replaced by the 2nd and 3rd lines which handle the same tasks. Did that change during your version issue?