Reporting

Why are mailserver settings in alert_actions.conf not being followed?

jcrabb_splunk
Splunk Employee
Splunk Employee

I have configured alert_actions.conf in $SPLUNK_HOME/etc/system/local/ but some alerts are still using “localhost” and not being received. I have configured that there are no other alert_actions.conf besides the default ones and btool output confirms that the settings are being applied correctly.

/opt/splunk/etc/system/local/alert_actions.conf                [email]
/opt/splunk/etc/system/local/alert_actions.conf                mailserver = testmailhost.com

Looking in python.log I show both the new mail server and localhost being applied.

Working

2017-06-14 15:45:02,017 -0400 INFO  sendemail:124 - Sending email.subject="Splunk Alert: Test_Alert_01", results_link="http://hostname:8000/app/search/@go?sid=scheduler__admin__search__<SID>", recipients=“[u’user@mydomain.com']", server="testmailhost.com"

Not Working

2017-06-14 15:45:02,017 -0400 INFO  sendemail:124 - Sending email. subject="Splunk Alert: Test_Alert_02", results_link="http://hostname:8000/app/search/@go?sid=scheduler__admin__search__<SID>", recipients=“[u’user@mydomain.com']", server=“localhost”

What could be causing this behavior?

Jacob
Sr. Technical Support Engineer
1 Solution

jcrabb_splunk
Splunk Employee
Splunk Employee

Mailhost settings can be applied in both alert_actions.conf and savedsearches.conf. If you have applied alert_actions.conf globally (this configuration can be applied at an app or user level) but some alerts are going to a different mail host than specific there, it could be configured under savedsearches.conf. If you review the spec file, you will find it also has a mail server setting:

http://docs.splunk.com/Documentation/Splunk/6.6.1/Admin/Savedsearchesconf

[savedsearch-name]
action.email.mailserver = <string>
* Set the address of the MTA server to be used to send the emails.
* Defaults to <LOCALHOST> (or whatever is set in alert_actions.conf).

As demonstrated above, this can be applied to a search and will take precedent over the setting in alert_actions.conf. Confirm that the affected alerts do not contain this potential configuration.

Jacob
Sr. Technical Support Engineer

View solution in original post

jcrabb_splunk
Splunk Employee
Splunk Employee

Mailhost settings can be applied in both alert_actions.conf and savedsearches.conf. If you have applied alert_actions.conf globally (this configuration can be applied at an app or user level) but some alerts are going to a different mail host than specific there, it could be configured under savedsearches.conf. If you review the spec file, you will find it also has a mail server setting:

http://docs.splunk.com/Documentation/Splunk/6.6.1/Admin/Savedsearchesconf

[savedsearch-name]
action.email.mailserver = <string>
* Set the address of the MTA server to be used to send the emails.
* Defaults to <LOCALHOST> (or whatever is set in alert_actions.conf).

As demonstrated above, this can be applied to a search and will take precedent over the setting in alert_actions.conf. Confirm that the affected alerts do not contain this potential configuration.

Jacob
Sr. Technical Support Engineer

surekhasplunk
Communicator

Hi,

I have a similar issue.

I am declaring action.email.subject = REMINDER: Cur in my savedsearches.conf in one of my apps. But when the email is getting triggered the subject isnt getting changed. Its still taking from the default alert_actions.conf file i.e. SplunkAlert-.

Why my subject is not getting changed ?

0 Karma
Get Updates on the Splunk Community!

Monitoring Amazon Elastic Kubernetes Service (EKS)

As we’ve seen, integrating Kubernetes environments with Splunk Observability Cloud is a quick and easy way to ...

Cloud Platform & Enterprise: Classic Dashboard Export Feature Deprecation

As of Splunk Cloud Platform 9.3.2408 and Splunk Enterprise 9.4, classic dashboard export features are now ...

Explore the Latest Educational Offerings from Splunk (November Releases)

At Splunk Education, we are committed to providing a robust learning experience for all users, regardless of ...