SMS Server Tools 3
This site is hosted by Kekekasvi.com
 Menu
Basic information:
Additional information:
Support:
Get SMS Server Tools 3:
Additional Options

 Sponsored links

 Search
Custom Search

 Visitor locations
 
 SMS Server Tools 3 Community
Welcome, Guest. Please login or register. Mon Mar 01, 2021 01:14
SMSTools3 Community » Help and support Bottom

[outdated] Frequent 'hang ups' of smsd daemon

  This topic is locked

Page:  1

Author Post
Member
Registered:
Jun 2009
Location: Germany
Operating system name and version: SLES10 SP3
Version of smsd: 3.1.14
Smsd installed from: sources
Name and model of a modem / phone: MTCBA-G-EN-F4-ED-EU (Modem with Accessory Kit) MultiModem GPRS Class 10, Quad Band (Ethernet)
Interface: TCP/IP

Have sometimes (on two servers) the same problem. It seems to be that the daemon after writing some errors will stop working with the modem.
See error log entries at bottom. At the top of these lines you see the first errors that called the alarm handler. I have a monitoring script that will restart the daemon in this case, so there was the first daemon restart right after the first lines.
After these messages (dont know how fast after) smsd stops talking to the modem but still move new files from outgoing to checked folder.

Doing a ps -ef|grep smsd |grep -v grep will show not only a line showing the running daemon but also a line containing:
[smsd] <defunct>
which means there was a broken task...

I have to restart sms daemon than to get it working again.

But I have no idea what maybe the cause...

error-log:


Axel

Administrator
Registered:
May 2009
Location: Jyväskylä, Finland
CMS 512 is a problem with GSM network, not a problem with communication between modem and smsd. If your script does not restart smsd after this error, how does the communication continue?

In my case, when a modem stops responding, I track the issue with the following alarmhandler:

#!/bin/bash

LOG="/var/log/smsd_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 "WDOG RESET 358405xxxxxx $5 $DATE" > $CONTROLFILE
  fi

fi
 
'bash' Syntax Highlight powered by GeSHi


After modem has stopped responding, restarting of smsd is not enough. The system needs to switch power off-on to get the modem working again.

In your case after smsd was restarted, the communication worked more than one hour. From the log you could check how the modem process has stopped. I assume that when smsd tried to close and re-open the port, opening has failed (with some error code and explanation), and because of this, the modem process has stopped. In this case the alarmhandler is also called, and you should track that message and try to restart the daemon.

[smsd] <defunct> is shown in the process list when modem process has stopped, but mainprocess still continues and spools messages. This is very abnormal case, and some external watchdog can be used to detect this kind of a zombie from the process list.

What kind is your current configuration? And do you run two servers simultaneously?

  This topic is locked

Page:  1

SMSTools3 Community » Help and support Top

 
Time in this board is UTC.  

Privacy Policy   SMS Server Tools 3 Copyright © Keijo Kasvi.