ast_carefulwrite: write() returned error: Broken pipe

[ronator]

hello there, it`s me again :)

I am running a 3-vici-cluster-setup with dedicated db-server. More or less everything works and seems fine; calls are transfered between the phone servers and performance has improved.
I'd like to thank all of you assisted me and spent their time to answer my questions (kumba, william, matt).

Right now, I am moving the agents to the cluster (more precisely, their phone extensions) and everytime when a call enters a queue via AGI, I get an error although everything goes on. I am not sure, if it is a real problem, because I read something about a bug in a certain asterisk-version, but maybe you can direct me where to look for:

Code: Select all

-- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----0--------------- completed, returning 0
[Jan  7 09:07:30]     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Jan  7 09:07:30]     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Jan  7 09:07:30]     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Jan  7 09:07:30]     -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)


[Jan 7 09:07:30] ERROR[1476]: utils.c:966 ast_carefulwrite: write() returned error: Broken pipe
[Jan 7 09:07:30] ERROR[1476]: utils.c:966 ast_carefulwrite: write() returned error: Broken pipe

Code: Select all

[Jan  7 09:07:30]     -- AGI Script agi-VDAD_ALL_inbound.agi completed, returning 0
[Jan  7 09:07:30]     -- Executing [010*000*030*201*8600057@default:1] Goto("SIP/audiocodes1-00000399", "default|8600057|1") in new stack
[Jan  7 09:07:30]     -- Goto (default,8600057,1)
[Jan  7 09:07:30]     -- Executing [8600057@default:1] MeetMe("SIP/audiocodes1-00000399", "8600057|F") in new stack


Since most imortant data can be found in the DB, I have no clue if this error is causing data loss or if it is just a bug. I even don't know if it is related to DB connection or AGI connection ...
If anyone has any clue, please be so kind and post it here !

Best wishes, r0n

vicibox-redux-3.0.6
wit AGC VERSION: 2.2.1-237
BUILD: 100510-2015

[ronator]

Sometime I can see this one here ... looks like agi-related

Code: Select all

 == Parsing '/etc/asterisk/manager.conf': [Jan  7 09:28:02] Found
[Jan  7 09:28:02]   == Manager 'sendcron' logged on from 127.0.0.1
[Jan  7 09:28:02] ERROR[4417]: utils.c:966 ast_carefulwrite: write() returned error: Connection reset by peer
[Jan  7 09:28:02] ERROR[4417]: utils.c:966 ast_carefulwrite: write() returned error: Broken pipe
[Jan  7 09:28:02]   == Manager 'sendcron' logged off from 127.0.0.1


[gmcust3]

U can safely Ignore them.

[williamconley]

dude! you gotta google it before you just ask!

this issue relates to the logging features within vicidial, we open the log file ... but have nothing to log right now. so we close the log file. Asterisk gets upset and tosses an error (that should, at most, be a "notice").

If you want to pay me, I'm extremely happy to find this in the source code and either remove this error entirely or at least edit it's level to "notice" It should only take a couple/few hours.

[ronator]

dude, of course i did that and I found the same answer you gave me. But I thought it was about another asterisk-version so I just wanted to be sure, that my gurus are of the same opinion as I am
Furthermore I thank you for offering your help, but I think it was on the asterisk-mailinglist, where they posted the code to patch asterisk. Now I know it's just the same error, and I try it on my own (as usual). If I won't succeed, I'll call you, bill

[williamconley]

come on! i've wanted to fix this one since the first time it appeared! but the accountant won't let me. something about "ROI" ...

[Kumba]

I believe this issue was mostly corrected in the new version of Asterisk we are using, 1.4.38. At a minimum, it pops up a LOT less then in 1.4.27.1. You can download the patched 1.4.38 source code from http://download.vicihost.com/required-apps/ if you want to compile it and see, but it causes no problems other then output to the logs.

[williamconley]

But that's not fun. I wanted to code warrior it.

[ronator]

Dear Vici-Gurus,

I have another issue that might be related to the source code of astguiclient. When I view the Live-Stats, there happens to be some agents on a 3-way-call. But I have not enabled 3-way-call for any campaign. In the past, I always recognized it as something like a bug, because e.g. it shows 2 agents in a 3-way-call, just when the call time is the same for the two calls. When I enter the conf-room, I can here the agent speaking to a customer and no one else, but the live-stats show me, it is on 3-way ... It seems to me, the web interface is interpreting something wrong ?!?

sometime I can even see 3 agents in a 3-way call (all got the same call time with a different customer) ...

any idea ?


vicibox-redux-3.0.6
wit AGC VERSION: 2.2.1-237
BUILD: 100510-2015

[mflorell]

Please open a new topic if you are going to discuss something different.

Also, I would recommend trying svn/trunk to see if the same issue exists.

[ronator]

yes, sir, I'll be aware of that in the future! I just noobishly thought one more posting is better than a completely new thread.

Nope, I cannot use svn-trunk, because the old system is running parallel using the same DB like the new systems, but astguiclient-version gotta be the same on all servers. Furthermore, I haven't finished moving the webserver to the new system and right by now I am just happy that everything is still working and I might upgrade soon in the future, but I will not change (or upgrade) a running system "just to see" if some errors disappear.

But you just gave me an answer I will try out. thanx!

[williamconley]

database structure doesn't change when updating within a version (ie: svn from 2.4 -> 2.4 will not change database ... it will just run better)

[Kumba]

The database structure changes within versions while that version is still within SVN. Once a version reaches release status, the DB schema changes are frozen for the most part.

[williamconley]

i stand corrected. the branch SVN no longer changes structure, but trunk may!

would it be safe to say that the .sql update for the trunk which contains the dbschema will always continue forward? (and never actually "change" instead?)

ie: if you are at the latest SVN with dbschema XXXX and a new svn commit occurs with db changes, it will be XXXX+1 and the changes between could be used to bring your present svn up to the latest svn structure? this would also mean that whatever your SVN trunk version is, your dbschema could be updated by making all changes AFTER your dbschema version to the end of the .sql file for trunk?

[ronator]

please regret my stupid question: are you talking to me ?

[williamconley]

The Vicidial Group, actually.

Concept is that moving forward in the "trunk", it would be good to know that the database structure will always move forward as well ... and that the dbschema will always increment forward

i do not know if, historically, vicidial's database structure has ever hiccuped in the trunk and "gone back to change something" or if it has always remained Forward-Moving.

[mflorell]

I know there were a couple schema hiccups in the past, but none since the last branch.

[okli]

come on! i've wanted to fix this one since the first time it appeared! but the accountant won't let me. something about "ROI" ...

Maybe this is of interest? There is a patch posted but my have to be adjusted for 1.4 branch.
https://issues.asterisk.org/view.php?id=14379

[shirker]

To change it from error to warning level, need to open /usr/src/asterisk/asterisk-1.4.XX.X./main/utils.c, line 966 and replace

Code: Select all

if (res < 0 && errno != EAGAIN && errno != EINTR) {
         /* fatal error from write() */
         ast_log(LOG_ERROR, "write() returned error: %s\n", strerror(errno));
         return -1;
      }

to

Code: Select all

if (res < 0 && errno != EAGAIN && errno != EINTR) {
         /* fatal error from write() */
         ast_log(LOG_WARNING, "write() returned error: %s\n", strerror(errno));
         return -1;
      }


then compile *

Now its just warning.. and no more catching eyes:

Code: Select all

 WARNING[19948]: utils.c:966 ast_carefulwrite: write() returned error: Broken pipe