[asterisk-bugs] [JIRA] (ASTERISK-28868) app_alarmreceiver.c does not call "eventcmd" with events as arguments or piping

[Paul Langner (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-28868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Langner updated ASTERISK-28868:
------------------------------------

    Attachment: app_alarmreceiver.c

This modification does the following:

Modification Lines 154-158: Changes the comment to specify calling user program specified in eventcmd with events as command-line arguments, versus piping to the command

Addition Lines 799-800: Declare 2x char strings to formulate the calling string with events

Change Lines 846-847 -> Lines 848-856: Create the calling string with events as args, and call string

> app_alarmreceiver.c does not call "eventcmd" with events as arguments or piping
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28868
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28868
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Applications/app_alarmreceiver
>    Affects Versions: 16.10.0
>         Environment: All
>            Reporter: Paul Langner
>            Severity: Minor
>         Attachments: app_alarmreceiver.c
>
>
> alarmreceiver.conf documentation states that app_alarmreceiver.c will pipe the alarm events to the user application specified by eventcmd in alarmreceiver.conf, yet it does not do this, and only calls the eventcmd program with no arguments, and no piping (Lines 154-158).
> To solve this issue, a command string needs to be created consisting of the user command specified by eventcmd, followed by the list of events, passed as command-line arguments, and this string called upon hang-up.  This is better than piping, as typically the events need to be parsed into human-readable form prior to e-mailing, etc. - which is easily done in a bash script.
> Up to this point, the approach (without fixing the issue) has been to enable writing individual events to the /tmp directory and then having the program specified in eventcmd search this directory for the most recent file, and then parse this to obtain the event.



--
This message was sent by Atlassian JIRA
(v6.2#6252)