This hasn't been touched since 2008-07-18, and upstream do not seem to
consider it an issue. I agree that it would be nice to resolve, but the
lack of duplicates and other comments is suggesting that this has a low
impact. The viability to investigate this further seems low priority.
If this is
This hasn't been touched since 2008-07-18, and upstream do not seem to
consider it an issue. I agree that it would be nice to resolve, but the
lack of duplicates and other comments is suggesting that this has a low
impact. The viability to investigate this further seems low priority.
If this is
** Changed in: asterisk
Status: Unknown = Invalid
--
Asterisk goes into a catastrophic log rotation loop when a conference recording
hits max file size
https://bugs.launchpad.net/bugs/249443
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
I'm unconfirming this for now - Asterisk 1.4 has changed to 64bit file
pointers, so a 2GB file won't cause it to receive SIGXFSZ. That's not to
say that ulimit won't, but I have been unable to trigger this (my
testing involved patching asterisk to open files with O_APPEND instead
of O_TRUNC and
(it might be worth mentioning, for anyone encountering an issue like this, that
the WAV files asterisk defaults to writing, will not be valid if they grow over
2GB, because it uses 32bit values internally).
Basically I suspect there are corner cases here where Asterisk isn't going to
handle
** Summary changed:
- Asterisk goes into a catastrophic log rotation loop when a conference
recording his max file size
+ Asterisk goes into a catastrophic log rotation loop when a conference
recording hits max file size
--
Asterisk goes into a catastrophic log rotation loop when a conference
