# Script to allow newsyslog to run commands



## Ruler2112 (Feb 11, 2010)

I have ejabberd installed on a box I built, along with bandersnatch for logging of instant messages.  Bandersnatch did not have a logging mechanism other than to screen, so I just dumped the output to /var/log/bandersnatch.log - AFAIK, the process needs to be restarted in order to release the log file.  Further, ejabberd does not respond to a SIG_HUP by re-opening it's log file and instead requires a command to be executed.  ([cmd=]ejabberdctl reopen-log[/cmd] for those interested.)

Since newsyslog does not have the ability to do anything but send a HUP signal to a process identified by a PID file, I decided to make something to get around this limitation.  The following is the simple script that I came up with for ejabberd - simply change two of the variables as described to use it for another such program.


```
#!/usr/local/bin/bash

###############################################################################
#                                                                             #
# Shell script to allow a command to be executed upon receipt of a signal.    #
# Designed to allow newsyslog to execute a command for software that either   #
# does not have a PID file or does not respond to a SIG_HUP signal and        #
# requires an external command to reopen its log file.                        #
#                                                                             #
###############################################################################
#                                                                             #
# Ruler's Common-Sense License:                                               #
#                                                                             #
#   You may use this script however you want to, but I don't warrant it to    #
#   be good for anything in particular, though it happens to work well for    #
#   me.  (I hate putting BS like this in, but I hate more being sued.)  If    #
#   you use this script, you must keep this license and credit to me in it    #
#   in the form of this block, even if you modify it for your own use.  If    #
#   you want to send me money for it, fantastic!  Send me a private message   #
#   on the freebsd.org forums and I'll give you my PayPal address. :-)  Even  #
#   just a simple 'thank you' would be nice.  If not, that's fine too.  All   #
#   hate mail/spam is sent directly to /dev/null                              #
#                                                       - Jim, AKA Ruler2112  #
#                                                                             #
###############################################################################
#                                                                             #
# History:                                                                    #
#                                                                             #
#   2010-02-11 by Ruler2112       Wrote initial version.                      #
#   2010-02-11 by Ruler2112       Released on freebsd.org forums.             #
#                                                                             #
###############################################################################

###############################################################################
#                      Variable Declaration Section                           #
# Set these variables to customize this script's behavior.                    #
###############################################################################

# What happens when a HUP signal is received.
HUP_ACTION="/usr/local/sbin/ejabberdctl reopen-log"

# How many seconds to pause between signal checks.  This will be the maximum
# amount of time between the time a signal is received and when the associated
# action occurs.  The lower this is, the more CPU time this script will use
# Higher values will decrease the amount of CPU power this script will consume
# but also increases the likelihood of a significant wait betwwen the sending
# of the signal and when the appropriate action is executed.
WAIT_TIME=3

# The name of a PID file that this script will generate.  Use this in
# /etc/newsyslog.conf   THIS SCRIPT WILL SILENTLY OVERWRITE THIS FILE,
# BE 100% CERTAIN THAT IT'S NOT AN IMPORTANT FILE!!!  I recommend using
# something in /var/run and naming it indirect-<name> for safety.
MY_PID_FILE="/var/run/indirect-ejabberd"

###############################################################################
# !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! #
###############################################################################
#                    This is the Beginning of the Script                      #
#                                                                             #
# Do not change anything below this line unless you know what you're doing!   #
###############################################################################

/bin/echo $$ > "$MY_PID_FILE"
trap "$HUP_ACTION" SIGHUP
trap "/bin/rm -f \"$MY_PID_FILE\";exit 0" SIGINT SIGTERM

while true; do
  /bin/sleep $WAIT_TIME
done
```


----------



## rbelk (Feb 12, 2010)

According to the newsyslog.conf man page you can use any signal.
Check out the end of the man page, the section named "*signal_number*", also see the Signal man page.


----------



## Ruler2112 (Feb 12, 2010)

I saw that section, but the problem is that I needed to execute a command in order to release/reopen the log files for these two daemons instead of sending a signal to the running daemon.  Since the bandersnatch daemon needs to be restarted and ejabberd does not respond to any signal to reopen the log file, I needed to find a way to accomplish this with the existing framework.  I'd thought of sending a SIG_KILL to them to forcibly kill each daemon, then restart them from a cron job, but think this script is a more elegant solution.  (Besides, restarting ejabberd would cause every jabber client in the building to disconnect.)


----------



## Ruler2112 (Feb 22, 2010)

I've patched this script to allow it to correctly respond to requests for the indirection script to die:


```
#!/usr/local/bin/bash

###############################################################################
#                                                                             #
# Shell script to allow a command to be executed upon receipt of a signal.    #
# Designed to allow newsyslog to execute a command for software that either   #
# does not have a PID file or does not respond to a SIG_HUP signal and        #
# requires an external command to reopen its log file.                        #
#                                                                             #
###############################################################################
#                                                                             #
# Ruler's Common-Sense License:                                               #
#                                                                             #
#   You may use this script however you want to, but I don't warrant it to    #
#   be good for anything in particular, though it happens to work well for    #
#   me.  (I hate putting BS like this in, but I hate more being sued.)  If    #
#   you use this script, you must keep this license and credit to me in it    #
#   in the form of this block, even if you modify it for your own use.  If    #
#   you want to send me money for it, fantastic!  Send me a private message   #
#   on the freebsd.org forums and I'll give you my PayPal address. :-)  Even  #
#   just a simple 'thank you' would be nice.  If not, that's fine too.  All   #
#   hate mail/spam is sent directly to /dev/null                              #
#                                                       - Jim, AKA Ruler2112  #
#                                                                             #
###############################################################################
#                                                                             #
# History:                                                                    #
#                                                                             #
#   2010-02-11 by Ruler2112       Wrote initial version.                      #
#   2010-02-11 by Ruler2112       Released on freebsd.org forums.             #
#   2010-02-22 by Ruler2112       Updated to correctly respond to kill signal.#
#                                                                             #
###############################################################################

###############################################################################
#                      Variable Declaration Section                           #
# Set these variables to customize this script's behavior.                    #
###############################################################################

# What happens when a HUP signal is received.
HUP_ACTION="/usr/local/sbin/ejabberdctl reopen-log"

# How many seconds to pause between signal checks.  This will be the maximum
# amount of time between the time a signal is received and when the associated
# action occurs.  The lower this is, the more CPU time this script will use
# Higher values will decrease the amount of CPU power this script will consume
# but also increases the likelihood of a significant wait betwwen the sending
# of the signal and when the appropriate action is executed.
WAIT_TIME=3

# The name of a PID file that this script will generate.  Use this in
# /etc/newsyslog.conf   THIS SCRIPT WILL SILENTLY OVERWRITE THIS FILE,
# BE 100% CERTAIN THAT IT'S NOT AN IMPORTANT FILE!!!  I recommend using
# something in /var/run and naming it indirect-<name> for safety.
MY_PID_FILE="/var/run/indirect-ejabberd"

###############################################################################
# !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! WARNING !!! #
###############################################################################
#                    This is the Beginning of the Script                      #
#                                                                             #
# Do not change anything below this line unless you know what you're doing!   #
###############################################################################

/bin/echo $$ > "$MY_PID_FILE"
trap "$HUP_ACTION" SIGHUP
trap "/bin/rm -f \"$MY_PID_FILE\";RUNLOOP=false" SIGINT SIGTERM
RUNLOOP=true
while [ $RUNLOOP = true ]; do
  /bin/sleep $WAIT_TIME
done
```

I'm not sure why the system doesn't allow the exit command inside the signal trap to terminate the loop, but it doesn't.  This fixes that.


----------



## Alt (Feb 22, 2010)

I got /usr/bin/wc and i counted your script's statistics:
321 bytes - code
4140 bytes - copyrights/comments/spam
Its about 93% of your script is comments xD its 1st bug..

Second - in this spam nothing points to version number


----------



## Ruler2112 (Feb 23, 2010)

Alt said:
			
		

> I got /usr/bin/wc and i counted your script's statistics:
> 321 bytes - code
> 4140 bytes - copyrights/comments/spam
> Its about 93% of your script is comments xD its 1st bug..
> ...



1.  Please identify what you consider to be spam.

2.  I've learned the hard way to comment to death anything I release or spend eternity answering the same questions repeatedly via private messages/e-mails.  Likewise, warning people to not set the PID file to /boot/loader is important because somebody will do it.  Either way, I do not consider comments to be a bug.

3.  There's a change log with the last revision date and what was done and by whom.  If you insist on a version number, please consider 2010-02-22 (the last entry in the history) to be the version number.  (I could do like M$ and say it's version 5.0.0.621.235546.57895132486621 RC2, but this actually means something.  )  Either way, it doesn't constitute a bug.

4.  If you don't like my scripts, don't use them.


----------



## rbelk (Feb 23, 2010)

I totally agree with you Ruler2112. It's a good rule to follow. I used to think it really didn't matter, but that has come back to haunt me in the future! Commenting, and some type of version control is often mandatory in programming jobs guys, so get used to it.

You script provides what most users and managers want.
1. What does this script do?
2. Your License.
3. The Versions.
4. The description of your Variables.
5. And a warning about modifications.

It look fine to me, and I wish more people, including me!, would follow.

Sorry but that comment about making a bug report just rubbed me the wrong way!


----------



## Alt (Feb 23, 2010)

I just noticed that comments for simply script file is near 13 times long than script itself =) You can just write good script without declaring about /dev/null or other things... You can just write "License BSD" insted of all this


----------

