Call files only processed once when pbx_spool.so loads, then never again


(Jerry Riggin) #1

PBX Version:14.0.13.40
PBX Distro:12.7.8-2008-2.sng7
Asterisk Version:13.36.0
System modules up to date as of today.

Problem: Call files are only processed when pbx_spool.so loads. Then the call files just sit there until asterisk reload and pbx_spool.so is loaded. (I made that module no_load so I could load it and confirm the issue. The module does not allow re-load or un-load.)

When I load the module, all call files in outgoing are processed, but any new ones added just sit there.

Anyone have a clue what would cause this?


(Dave Burgess) #2

That’s completely new. Have you submitted a ticket to go along with the support you might get from here?

To be clear - I’ve never heard of this problem happening. You are the first person I’m aware of that’s reporting it. If it was a common problem, the forums would be on fire!


(Joshua C. Colp) #3

I also haven’t seen anything on the Asterisk side, and call file support is something that hasn’t changed in… a long time.


(Jerry Riggin) #4

It seems it must be an issue with my pbx_spool.so, so I replaced with copy form same version of 14 that is working, but it made no change. So I tested on that PBX 14.0.13.40 and same result – call file sat there. Then I tested on FreePBX 15.0.16.77 and — SAME RESULT! It worked on the next 14.0.13.40 I tried, so I copied the pbx_spool.so to the first machine and it still doesn’t work, so I am convinced it is not the module but some background or directory watching daemon that is not running. I have not used call files for a while except on that 3rd 14.0.13.40, and uses them constantly. But I am surprised no one else has complained of this when I can reproduce it on both 14 and 15 machines.

Anyone have a clue what be preventing pbx_spool.so from reading a call file from /var/spool/asterisk/outgoing?


#5

Can you paste the output of

ls -l /var/spool/asterisk/outgoing 

when calls are not being processed? Possibly a problem with ownership or timestamps.


(Jerry Riggin) #6

The only time calls ARE processed is when pbx_spool.so is loaded.

$ ls -l /var/spool/asterisk/outgoing
total 4
-rw-rw-rw- 1 asterisk asterisk 157 Nov 10 12:26 agent_call2
$ date
Tue Nov 10 12:49:00 EST 2020
$ cat /varspool/asterisk/outcoung/agent_call2
Channel: Local/5561004@from-internal
Callerid: 7775551212
MaxRetries: 1
RetryTime: 10
WaitTime: 20
Context: from-internal
Extension: 1004
Archive: yes


#7

module load pbx_spool ?


(Jerry Riggin) #8

CLI> module show like pbx_spool.so
Module Description Use Count Status Support Level
pbx_spool.so Outgoing Spool Support 0 Running core
1 modules loaded


(Jerry Riggin) #9

It seems that whatever asterisk is using to watch the outgoing folder is not running/working. I wonder what service/program that is?


#10

That shows it running and loaded,

try touching the call file stuck 10 seconds in the future, while in asterisk cli

!touch -amd 'now +10 sec ' call-file


#11

It is the pbx_spool.so itself

/usr/src/asterisk-n.n.n/pbx/pbx_spool.c


(Jerry Riggin) #12

So I touched it and it it ran the call file. Why would that be? The file was not created in outgoing, it was moved there.


#13

work around, touch the file 1 second in the future before moving it. (The module does need the inotify library . . .)


(Jerry Riggin) #14

Strange! But workable.
Thanks, @dicko


#15

As a diagnostic, install inotify-tools (if not installed already)

inotifywait -m -r --timefmt '%F %T' --format '%T %w%f %e' /var/spool/asterisk/outgoing


(Jerry Riggin) #16

@dicko That actually solved the mystery. The original issue was with a system that uses a PHP program executing system commands to move the files, and they were just piling up in outgoing. This was most likely solved by replacing pbx_spool.so, but I didn’t know my testing methodology was severely flawed. I was using WinSCP to move the files to outgoing on the other machines I tested. Your suggestion of inotifywait showed me that a WinSCP move does not produce the same output as when I use linux mv: then the output includes the filename and the call file is handled immediately by asterisk. Moral of the story: Don’t use WinSCP to move files to outgoing.
Thanks again, dicko.


(system) closed #17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.