[Home]

Summary:ASTERISK-06183: Bug in retrieve_file for ODBC. open method always return -1.
Reporter:Omar Belakhdar (belakdar)Labels:
Date Opened:2006-01-24 16:24:33.000-0600Date Closed:2006-05-04 10:53:31
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_voicemail
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I've installed the last released asterisk 1.2.2 on my own HLFS system with a 2.6.14.3 kernel. I've also a 2 FXO/ 1 FXS digium card on it. Every thing is working correctly.

For ODBC, I'm using UnixODBC with pgsql. The messages are written corretly to the database and also their number is correctly reported by VoicemailMain dialogue.

However, after reading the time/day of the new message, the system hangup without playing the message and automatically reports that it "couldn't open /var/spool/.../msg0000.WAV, from the file.c (ast_filehelper) and "Unable to open /var/.../msg0000" from the file.c (ast_streamfile) methods.

After some dubbeguing (I've a sptripped system, I don't have access to all symbols), it seems like the temporary files are not created at all and the open method return always -1 which prevent from creating the file of the message.  The directory is writable for the asterisk user but not for the group. Even the description file of the message is created correctly as I've seen.

My question is: does asterisk create the file even if the message is empty or not? If it doesn't so the problem could come from the ODBC part as asterisk is not able to read the data even if message is correctly recorded in the database.

The message is reported as read and thus becomes old. I checked that from the code and this happens from the playing_message method as expected.

Many thanks.

Omar.
Comments:By: Jason Parker (jparker) 2006-01-27 18:53:39.000-0600

Yes, the file will be saved even if the field is null.  What is the value in msgnum?  It must be 0 for the first VM, and 1 higher for each VM beyond the first.

By: Omar Belakhdar (belakdar) 2006-01-29 03:28:10.000-0600

Hi,
Thanks for your answer and help.
The msgnum is incremental and every new or new "becoming old" VM is set to the last value in DB + 1. So, every thing is working correctly except that the file is not created and I cannot listen to its content.

As I explained before, the message being read is considered as old just after the system disconnects the phone and the console shows that app_voicemail (play_message) couldn't open file /var/.../INBOX/msg0000.WAV.

The returned value of the open method in retrieve_file: fd is always -1. It seems that the open creation is encountering special situation but the /var/spool/asterisk/voicemail is writable for the asterisk user!

Is there any special setup I have to make in voicemail.conf except the odbcstorage variable?

Thanks for your time.

By: Vincent Dubois (vdubois) 2006-02-01 10:21:21.000-0600

I got the same problem here...
Voicemail storage in ODBC works fine, the message is recorded correctly in the DB.

But from VoicemailMain it's impossible to listen to it.
Asterisk does create the files when i'm inside VoicemailMain
Unfortunatly the .WAV is empty
drwx------  2 voicemail asterisk 4096 Feb  1 12:22 .
drwx------  4 voicemail asterisk 4096 Feb  1 11:30 ..
-rw-r--r--  1 voicemail asterisk  148 Feb  1 12:22 msg0000.txt
---------x  1 voicemail asterisk    0 Feb  1 12:22 msg0000.wav
So the problem comes from the code that creates the files...

Hope this helps a little

By: Lance Kimes (lkimes) 2006-02-07 13:23:59.000-0600

See Issue# 6337.  I posted the patch to fix this, but Digium rejected it and told me to run asterisk as root. Given that kind of response, we've begun exploring Cisco CallManager as a possible PBX manager instead.

By: Tilghman Lesher (tilghman) 2006-02-09 14:15:44.000-0600

lkimes:  no, you were told that there was an alternate solution to your patch, as implemented in bug ASTERISK-5774.

By: Tilghman Lesher (tilghman) 2006-04-11 17:46:37

Is this still an issue in 1.2.6?

By: Serge Vecher (serge-v) 2006-05-04 10:53:31

no response from reporter. Presumably fixed by 6061