0

I'm trying to use a Bash script to take certain log entries and generate a more user friendly notification email via exec with swatch. However, what I'm finding is when swatch picks up the corresponding log file lines to match for a specific application, the Bash script is erroring out with sh: script: No such file or directory.

This seems to be due to the log line in question outputting something like: [2017-05-22 20:00:41] somehost someapp[3999]: INFO: <script>: bad stuff happened bruh

I've tested the script out with output from things like rsyslog to /var/log/messages and secure, which don't cause problems. This specific application I'm trying to make these notifications for is only problematic because the log lines themselves include <script>, which I can't exclude. Specifically, this seems to trip up with just <script as I've messed around with removing chars in those log lines that might be interpreted as something besides text.

Any ideas on how to not get the Bash script to try to interpret <script> as a file/directory in the original log? It's even fine if the suggested answer is to simply rip that out of the line. I've tried using sed -i 's/\<script\>//g ${@} to remove <script> to strip and store to a temp variable with the intention of doing something like: echo -e "${plainenglish}\n\nThe original log message is:${logline}" >> $outputfile but I get the same error noted above.

Edit: More info. The problem application in question is Kamailio, where most of the logging from routing execution is written by the xlog module. By default, xlog shoves <script> in front of everything you log. The module does include a parameter override (modparam) for prefix, which defaults to <script>.

Ruhrohshingo
  • 11
  • 3
  • Can you post a minimal example of the Bash script you're using? – calico_ May 22 '17 at 21:22
  • This doesn't happen by itself. Maybe you're calling `eval`, `sh`, `ssh`, `su` or similar improperly. Also, double check that you're using `bash` because your error message seems to say you're using `sh` – that other guy May 23 '17 at 00:25
  • Here're some snippets: From swatch's configuration: `watchfor /Pretend this is regex/ exec "bash /path/to/somescript.sh $_"` From Bash script: ` #!/bin/bash #<--which bash does indicate this is /bin/bash rather than /bin/sh HOST=$(echo -e $@ | cut -d " " -f 3) MSG="This is a notification of blah in plain English. See the offending log below:" echo -e "\n\n${@}" >> $MSG ` – Ruhrohshingo May 23 '17 at 13:03
  • @calico_ Sorry, see previous for snippet which got mangled and couldn't edit to fix proper. @thatotherguy Except it doesn't appear I am? Doing which bash returns /bin/bash, which is what I'm using in the script. This is also on CentOS 6.8, so `script` is a legal command. Maybe it's inadvertently invoking? – Ruhrohshingo May 23 '17 at 13:11
  • So I have a work around that doesn't necessarily answer the question as posed, but does solve the problem. – Ruhrohshingo May 23 '17 at 14:55

1 Answers1

0

I realize this is a bit specific for question and solution, but here's a summary followed by suggestion:

-Using Kamailio (SIP server/proxy, etc.) with xlog configuration logging calls to some logfile (e.g.: /var/log/kamailio)

-Using swatch or some tool to grab specific Kamailio logs with the intent of notifying, such as routing failure or suspicious requests received (e.g.: +18928751123@1.1.1.1:5060)

-Using Bash shell script to sanitize/normalize the corresponding log line in some manner for dispatch.

The solution: set xlog's prefix modparam to something that will not be interpreted by Bash as a legal command (script is a legal command) when attempting to process the log lines.

It seems Bash processing gets thrown astray as soon as it hits the <script> line in the default xlog produced logfile lines.

Ruhrohshingo
  • 11
  • 3