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

[jerryriggin]

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?

[cynjut (Dave Burgess)]

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!

[jcolp (Joshua Colp)]

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

[jerryriggin]

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?

[dicko]

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.

[jerryriggin]

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

[dicko]

module load pbx_spool ?

[jerryriggin]

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

[jerryriggin]

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

[dicko]

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

[dicko]

It is the pbx_spool.so itself

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

[jerryriggin]

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.

[dicko]

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

[jerryriggin]

Strange! But workable.
Thanks, @dicko

[dicko]

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

[jerryriggin]

@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.