Asterisk
  1. Asterisk
  2. ASTERISK-16764

[patch] Call files generate two warning logs after each successful completion

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: PBX/pbx_spool
    • Labels:
      None
    • Mantis ID:
      18089
    • Regression:
      No

      Description

      Call files with 1.8-rc2 with Issue ASTERISK-16608 patch works for me.

      The problem reported here are two warning logs that are generated for each successful call file. (See Additional Information)

      Each warning log occurs at "RetryTime" seconds after the call-file completion or previous warning log.

      While these warnings seem harmless, it indicates the queue is maintaining multiple instances of the call file, (or inotify is generating them during the processing).

      If HAVE_INOTIFY is undefined in pbx_spool.c, the problem goes away.

                • ADDITIONAL INFORMATION ******

      In "demo" context:
      exten => 502,1,Answer
      exten => 502,n,Hangup

      Using call-file.txt:

      Channel: Local/502@demo
      Extension: s
      Priority: 1
      Callerid: 1111
      MaxRetries: 0
      RetryTime: 10
      WaitTime: 50

      $ mv call-file.txt /var/spool/asterisk/outgoing/

      == Verbosity 5 console ==
      – Attempting call on Local/502@demo for s@:1 (Retry 1)
      – Executing [502@demo:1] Answer("Local/502@demo-0964;2", "") in new stack
      > Channel Local/502@demo-0964;1 was answered.
      – Executing [s@demo:1] Wait("Local/502@demo-0964;1", "1") in new stack
      – Executing [502@demo:2] Hangup("Local/502@demo-0964;2", "") in new stack
      == Spawn extension (demo, 502, 2) exited non-zero on 'Local/502@demo-0964;2'
      == Spawn extension (demo, s, 1) exited non-zero on 'Local/502@demo-0964;1'
      [Oct 4 10:17:24] NOTICE[3402]: pbx_spool.c:357 attempt_thread: Call completed to Local/502@demo

      [Oct 4 10:17:34] WARNING[3225]: pbx_spool.c:400 scan_service: Unable to open /var/spool/asterisk/outgoing/call-file.txt: No such file or directory, deleting

      [Oct 4 10:17:44] WARNING[3225]: pbx_spool.c:400 scan_service: Unable to open /var/spool/asterisk/outgoing/call-file.txt: No such file or directory, deleting
      ==

      HAVE_INOTIFY is defined in pbx_spool.c

      Using Issue ASTERISK-16608 patch:
      http://svnview.digium.com/svn/asterisk?revision=290066&view=revision

      Related to Issue ASTERISK-16097 Reported description.

        Activity

        Hide
        Tilghman Lesher added a comment -

        Patch uploaded that solves the problem for me. The issue was in the transition from IN_CREATE to IN_CLOSE_WRITE, it was ignored that we write several times to the callfile while it is in-queue. When we wrote to the callfile, IN_CLOSE_WRITE forced the file to be requeued erroneously. This has been fixed by requiring an IN_CREATE before IN_CLOSE_WRITE, such that subsequent writes are ignored.

        Show
        Tilghman Lesher added a comment - Patch uploaded that solves the problem for me. The issue was in the transition from IN_CREATE to IN_CLOSE_WRITE, it was ignored that we write several times to the callfile while it is in-queue. When we wrote to the callfile, IN_CLOSE_WRITE forced the file to be requeued erroneously. This has been fixed by requiring an IN_CREATE before IN_CLOSE_WRITE, such that subsequent writes are ignored.
        Hide
        Michael Keuter added a comment -

        @tilghman:

        I just tested your patch in 1.8.0 final and now I again get the error, but this time only once after "RetryTime". Without your patch I get no warning (because inotify is disabled).

        Show
        Michael Keuter added a comment - @tilghman: I just tested your patch in 1.8.0 final and now I again get the error, but this time only once after "RetryTime". Without your patch I get no warning (because inotify is disabled).
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 294569

        U branches/1.8/pbx/pbx_spool.c

        ------------------------------------------------------------------------
        r294569 | tilghman | 2010-11-10 17:13:38 -0600 (Wed, 10 Nov 2010) | 8 lines

        Properly queue files with inotify(7).

        (closes issue ASTERISK-16764)
        Reported by: abelbeck
        Patches:
        20101021__issue18089.diff.txt uploaded by tilghman (license 14)
        Tested by: tilghman

        ------------------------------------------------------------------------

        http://svn.digium.com/view/asterisk?view=rev&revision=294569

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 294569 U branches/1.8/pbx/pbx_spool.c ------------------------------------------------------------------------ r294569 | tilghman | 2010-11-10 17:13:38 -0600 (Wed, 10 Nov 2010) | 8 lines Properly queue files with inotify(7). (closes issue ASTERISK-16764 ) Reported by: abelbeck Patches: 20101021__issue18089.diff.txt uploaded by tilghman (license 14) Tested by: tilghman ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=294569
        Hide
        Digium Subversion added a comment -

        Repository: asterisk
        Revision: 294570

        _U trunk/
        U trunk/pbx/pbx_spool.c

        ------------------------------------------------------------------------
        r294570 | tilghman | 2010-11-10 17:14:45 -0600 (Wed, 10 Nov 2010) | 15 lines

        Merged revisions 294569 via svnmerge from
        https://origsvn.digium.com/svn/asterisk/branches/1.8

        ........
        r294569 | tilghman | 2010-11-10 17:13:37 -0600 (Wed, 10 Nov 2010) | 8 lines

        Properly queue files with inotify(7).

        (closes issue ASTERISK-16764)
        Reported by: abelbeck
        Patches:
        20101021__issue18089.diff.txt uploaded by tilghman (license 14)
        Tested by: tilghman
        ........

        ------------------------------------------------------------------------

        http://svn.digium.com/view/asterisk?view=rev&revision=294570

        Show
        Digium Subversion added a comment - Repository: asterisk Revision: 294570 _U trunk/ U trunk/pbx/pbx_spool.c ------------------------------------------------------------------------ r294570 | tilghman | 2010-11-10 17:14:45 -0600 (Wed, 10 Nov 2010) | 15 lines Merged revisions 294569 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r294569 | tilghman | 2010-11-10 17:13:37 -0600 (Wed, 10 Nov 2010) | 8 lines Properly queue files with inotify(7). (closes issue ASTERISK-16764 ) Reported by: abelbeck Patches: 20101021__issue18089.diff.txt uploaded by tilghman (license 14) Tested by: tilghman ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=294570
        Hide
        David Woodhouse added a comment -

        The use of IN_CLOSE_WRITE seems to have broken the smsq utility. It hard-links its call file into the queue directory, causing an IN_CREATE event. But there is no subsequent IN_CLOSE_WRITE because smsq is actually following the rules and not writing to the queue file in-place.

        In https://issues.asterisk.org/jira/browse/ASTERISK-18331 I fix smsq to use rename() instead of link() followed by unlink(), but it concerns me that the queue management is now penalising correct behaviour in order to pander to broken users.

        Or have the rules changed?

        Show
        David Woodhouse added a comment - The use of IN_CLOSE_WRITE seems to have broken the smsq utility. It hard-links its call file into the queue directory, causing an IN_CREATE event. But there is no subsequent IN_CLOSE_WRITE because smsq is actually following the rules and not writing to the queue file in-place. In https://issues.asterisk.org/jira/browse/ASTERISK-18331 I fix smsq to use rename() instead of link() followed by unlink(), but it concerns me that the queue management is now penalising correct behaviour in order to pander to broken users. Or have the rules changed?

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development