Summary:	ASTERISK-01662: Loop when HD fills up
Reporter:	denon (denon)	Labels:
Date Opened:	2004-05-20 01:07:18	Date Closed:	2011-06-07 14:10:26
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When the HD or partition the * server is saving VM to fills up, you get thousands of the following on the console. So many, that the system's proc seems to tweak, and the UI is unusable until you kill it off from another console: May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1484 ast_write: Failed to write data to channel monitor write stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1185 ast_read: Failed to write data to channel monitor read stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1484 ast_write: Failed to write data to channel monitor write stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1185 ast_read: Failed to write data to channel monitor read stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1484 ast_write: Failed to write data to channel monitor write stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1185 ast_read: Failed to write data to channel monitor read stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1484 ast_write: Failed to write data to channel monitor write stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1185 ast_read: Failed to write data to channel monitor read stream May 19 23:56:37 WARNING[1828881]: format_wav.c:496 wav_write: Bad write (0): No space left on device May 19 23:56:37 WARNING[1828881]: file.c:227 ast_writestream: Translated frame write failed May 19 23:56:37 WARNING[1828881]: channel.c:1484 ast_write: Failed to write data to channel monitor write stream ... you get the idea. There should probably be some tests done for drive space/etc before recording. :)
Comments:	By: James Golovich (jamesgolovich) 2004-05-20 01:21:50 I really don't like having apps checking on things like disk space available.  The unixish mindset is to have one app do one thing.  So it would be more appropriate to have something checking for full diskspace rather than add some generally nonportable code to the core. Most other applications have pretty crazy results when the drive is full.  Perhaps there are certain modules that could use some tweaking in certain spots to exit on some of these odd error conditions Adding a second thought here: I guess we could add some kind of configurable ratelimit for number of lines to log per second or something.  I'm not sure I have a use for something like this, but I can see a bit of usefulness with it. edited on: 05-20-04 00:24 By: Mark Spencer (markster) 2004-05-20 02:01:25 I'm not even sure that you can say "Asterisk should work properly when there is no disk space left when doing an operation which writes to disk", but in any case, this is at best a minor bug since you don't generally expect applications to run normally when out of disk space. By: denon (denon) 2004-05-20 02:14:25 Oh, right -- in the core is fine.  I expect asterisk to halt it's current process, not deny service to everything just because it can't write a voicemail. Heck, all you need to do to take down a * server, is set up a script to leave repeated voicemails until the volume is full. Denial of service with no access to the box (aside from pstn, which everyone has). Commenting on James' addition: That might be a wise idea, most OS logging mechanisms are doing that type of thing.  "This message repeated X times." edited on: 05-20-04 01:21 By: Mark Spencer (markster) 2004-05-20 02:35:54 Right, that's a terribly efficient denial of service.  Oh did we mention that voicemail has timeouts and a maximum number of messages per mailbox?  It's no more a denial of service against asterisk than any other PBX.  Size your disk for your system -- this is a PC after all.  Did you try hanging up the call to see if the messages would stop?  In any case I just don't think this is that big an issue.  No reasonable sysadmin would see this because they wouldn't let their disk usage get out of hand any more than they would on a web server or file server.  If you have any useful patches to submit to improve the situation, I'd love to see it, but if not, then I don't see this going anywhere because i'm certainly not going to waste my time with it at this juncture. If you want to limit lines of log per second, just use syslog facility instead of asterisk's logger (it's a configuration option in logger.conf) and it will rate limit at least for the same message. By: Brian West (bkw918) 2004-05-20 21:04:57 And you should also monitor your disk space with something like nocol and snips or other such system monitoring setup.  Thats how I do it.   bkw By: denon (denon) 2004-05-20 23:01:08 Yeah, it was a fluke that it happened  - the monitoring had broke. I just figured that the errors should be dealt with, and that the user leaving voicemail should maybe get a "This mailbox is full" or such (instead of just getting disconnected after the beep).  I realize that no admin should let it happen, but I'm of the mind that the system should treat it gracefully when it does.  Obviously I'm alone in this mindset - that's fine, now I know. edited on: 05-20-04 21:58 By: Mark Spencer (markster) 2004-05-21 22:56:51 lol that's not such a bad failure, but like i said, if you want to submit a patch i'll be happy to apply it.  if not, let me know and i'll just close this out as "suspended".  The trouble is that this could become an endless spin of time because there are many places that things get written to disk so trying to fix everything to fail more gracefully. By: Mark Spencer (markster) 2004-05-24 15:56:25 I won't say "won't fix" because if someone contributes patches I"ll considered them, otherwise I really don't think this is worth a time investment on my end.