aschneck wrote
yep, the term CPU-intensive was a theoretical, dont know how to better explain what I mean that it normally would be better, to filter at the first step :-)
Alarmhandler is the first step which can do the filtering, in practice.
This software is used at least 80 countries, likely much more, and there are differences in SMSC's and also users have different needs for "filtering". It makes no sense if everything is included in the code, with a large number of configuration settings etc., when alarmhandler can be used for filtering with some simple lines of scripting.
aschneck wrote
OK, so I'll procede with my already started 'job' to try to find out which error I should alert and which not
The main reason behind these question is / was to find out at what errors I have to try to restart the daemon or check the modem.
Yes, It's much better in results.
There is a list of possible error messages available in
this page. However, it's preliminary list and from 3.2beta0. Currently there might be some differences to 3.1.14 because those versions of code are not yet synchronized.
For example, in some system I have this kind of alarmhandler:
#!/bin/bash
LOG="/var/log/smstools/alarmhandler.log"
CONTROLFILE="/var/lib/smsd/application/control"
# $1 the keyword ALARM
# $2 a date in the format yyyy-mm-dd
# $3 a time in the format hh:mm:ss
# $4 the alarm severity (1 digit number)
# $5 the modem name or SMSD
# $6 the alarm text
echo "$2 $3,$4, $5: $6" >> $LOG
if echo -n "$6" | grep "Modem is not ready to answer commands" >/dev/null; then
if [ ! -f $CONTROLFILE ]
then
DATE=`date +"%Y-%m-%d %T"`
echo "${DATE},1, $5: Alarmhandler created request for reset." >> $LOG
echo "KEYWORD RESET SMS_TO $5 $DATE" > $CONTROLFILE
fi
fi
'bash' Syntax Highlight powered by GeSHi There is an external process which see if reset is needed, and if it is:
- smsd is stopped
- all modems get power-off-delay-on with USB controlled relay and AC adapter
- controlfile is removed
- smsd is started
- SMS notification is created to administrator