Hey everybody!

I must say great tool set, its easy and straight forward.

I'm currently using SMS tools 3 on OSX it works, not sure if anybody else has tried this or not. But I can confirm this.

With that out of the way I do have some problems they may or may not relate to OSX.

I run a fairly simple setup 1 GSM modem ( possibly 2 ) and a single server. The server is also used for a database system that about 3-5 computers access throughout the day. It is not a very heavy load(?).

I have created a web front end for SMS tools to be used on the client machines. Everything works....

Since it has been put to use I have had to restart the process several times, if fact it has not lasted a full day yet.

The problems have been, first my event handle script returns an error:
Running eventhandler: /usr/local/bin/receiveEvent.sh RECEIVED /var/spool/sms/incoming/GSM1.4k2LUj 2009-09-16 19:11:19,3, GSM1: Done: eventhandler, execution time 0 sec., status: 256 2009-09-16 19:11:19,3, GSM1: ALERT: problem with eventhandler, result 1



I would like to use the alert handler but would like some guidance or examples.

Eventually the smsd process fails and and no more sms-ing for the office.
This is my event handler script.... No doubt I'm doing something wrong.


Thanks in advance

-M@

The script should always use exit 0 as a return value. However, this should not cause a freezing.

Does the problem occur every time when a message is received and eventhandler is executed? How do you see that restarting is needed, what is in the log and in the ps list (is it in <defunct> state)?

Hey Keke!

The problem occured first when about 50 messages were sent at once. Up to that point we had problems for at least 3 days though usage was only testing, this was about just simple back and forth to make sure the database was storing messages correctly.

This is one of the process termination events in the logs from a few days ago. When the bulk messages were sent. The process had been up for a few days prior though.

2009-09-14 16:18:02,7, GSM1: Command is sent, waiting for the answer 2009-09-14 16:18:09,2, smsd: Conflict with .LOCK file in the spooler: /var/spool/sms/outgoing/FRprMb /var/spool/sms/checked 2009-09-14 16:18:09,2, smsd: Fatal error: Cannot move /var/spool/sms/outgoing/FRprMb to /var/spool/sms/checked. Check file and dir permissions. 2009-09-14 16:18:09,2, smsd: Smsd mainprocess terminated abnormally. PID: 47428. 2009-09-14 16:18:11,7, GSM1: <- +CMGS: 217 OK 2009-09-14 16:18:11,5, GSM1: SMS sent, Message_id: 217, To: 0431437189, sending time 12 sec. 2009-09-14 16:18:11,7, GSM1: Running eventhandler: /usr/local/bin/receiveEvent.sh SENT /var/spool/sms/checked/FRprMb 217 2009-09-14 16:18:11,3, GSM1: Done: eventhandler, execution time 0 sec., status: 256 2009-09-14 16:18:11,6, GSM1: ALERT (continues, 81): problem with eventhandler, result 1 2009-09-14 16:18:11,6, GSM1: Deleted file /var/spool/sms/checked/FRprMb 2009-09-14 16:18:11,2, GSM1: Modem handler 0 terminated. PID: 47429, was started 09-09-13 16:34:58.

Also I get two processes running. This is what 'ps -e | grep sms' returns.

21484 ?? 0:00.04 smsd 21485 ?? 0:00.25 smsd 22119 ttys000 0:00.00 grep sms

Is that correct?

I will also note that the process was restarted and I preformed a test by sending the about 50 text messages of about 100 characters and requesting a reply. Everything went to plan The messages went out and I also got the replys. It was not until the day after the process terminated again. I lost the log with that termination info.

Thanks again.

-Mattb

The process list is correct, there should be one mainspooler and one devicespooler for each modem.

The problem is caused by the name of SMS file. The file created to the outgoing folder has an unique name, but there has just been a message file which had the same name. As the previous message was not yet sent, mainspooler was unable to move a new file to the checked folder.

Much more longer randomized name could be used to prevent this kind of conflict. However, a conflict can still happen.

You can use a setting keep_filename = no in the smsd.conf. With this setting a new unique filename is created each time when a message file is moved from folder to another.

Awesome!

I will give it a try!

You said before that the event handler shouldn't cause the process to break, I have been receiving alerts with every message could this be simply because I have the script returning 1 and not 0?

Thanks Keke, you are doing an great job in the forums!

Thanks!

Yes, the return value 1 causes alerts to the log. In usual cases value 0 should always be used.

Return value other than zero indicates an error in the script. It can be used to send an SMS alert to the administrator. There is admin_to setting in the smsd.conf file, it's a GSM number. For example, if an eventhandler detects that filesystem is not writable, it can return a nonzero value. You will then receive an SMS containing something like: "Sms3: GSM1, problem with eventhandler, result 5". From the SMS you can know that 5 means a fatal filesystem failure.

Hey Keke, would there be any proformance loss from running the log level at debug(7) for long periods of time?

Cheers

Logging with level 7 is not a performance issue, but depending on number of modems and how often they are checked, the logfile may grow very much. To avoid this, it's recommended to use loglevel = notice and smart_logging = yes in the configuration file. With these settings any troubles, but only troubles, are logged into the smsd_trouble.log and smsd.log will not grow unnecessarily.

Do you now receive e-mails from this board?

Thanks again Keke,

I am receiving emails now, thanks.

In terms of volume 30-50 SMS's at once is really not to much for a single server and single GSM modem? I have another GSM modem I can use if this would assist in breaking the load up? As I am unaware of what setups and loads people typically use.
I'm assuming I have a light load and the one server is enough to deal with my load?

Cheers.

30-50 SMS's is a light load, but of course it takes 4-6 minutes to get them sent all. You can use additional modem(s) for reducing the sending time, if necessary. However, then you will have a different number of sender for some SMS, because the GSM number of a SIM card cannot be changed.

Without any additional settings for queues, you can use as much modems you need and they will all serve the default queue (/var/spool/sms/checked).

Practical limit with a current version (3.1.5) of smsd on systems with very heavy load is about 10 - 15 modems and about 500 -600 messages per hour per each modem.

Hey!

I thought that my load was not very heavy. I am still trying to iron out the kinks in my setup.

This is what 'ps -e' gives me, currently it appears to be running but no messages are being sent or received. Do you know why the brackets are around one of the processes?

41500 ?? 0:03.44 smsd 41501 ?? 0:00.00 (smsd)

This is the trouble log after a day usage(not heavy). I have seen this before. It appears the modem is failing to communicate. Is it possible the GSM modem is not initialized correctly? Or maybe the signal is dropping out.

2009-09-18 15:20:45,3, GSM1: Unexpected input: NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER NO CARRIER 2009-09-18 15:20:45,7, GSM1: -> AT 2009-09-18 15:20:45,7, GSM1: Command is sent, waiting for the answer 2009-09-18 15:20:45,7, GSM1: <- OK 2009-09-18 15:20:45,6, GSM1: Pre-initializing modem 2009-09-18 15:20:45,7, GSM1: -> ATE0+CMEE=1 2009-09-18 15:20:45,7, GSM1: Command is sent, waiting for the answer 2009-09-18 15:20:46,7, GSM1: <- +CSQ: 21,0 OK 2009-09-18 15:20:46,6, GSM1: Checking if modem needs PIN 2009-09-18 15:20:46,7, GSM1: -> AT+CPIN? 2009-09-18 15:20:46,7, GSM1: Command is sent, waiting for the answer 2009-09-18 15:20:56,7, GSM1: put_command expected (READY)|( PIN)|( PUK)|(ERROR), timeout occurred. 1. 2009-09-18 15:20:56,7, GSM1: <- +CREG: 0,1 OK 2009-09-18 15:20:56,2, GSM1: PIN handling: expected READY, modem answered +CREG: 0,1 OK 2009-09-18 15:20:56,2, GSM1: Modem handler 0 terminated abnormally. PID: 41501. 2009-09-18 15:20:47,7, GSM1: -> AT+CREG? 2009-09-18 15:20:47,7, GSM1: Command is sent, waiting for the answer 2009-09-18 15:20:57,7, GSM1: put_command expected (\+CREG:.*OK)|(ERROR), timeout occurred. 1. 2009-09-18 15:20:57,7, GSM1: <- 2009-09-18 15:20:57,3, GSM1: Error: Unexpected answer from Modem after +CREG?, waiting 1 sec. before retrying

When I run the log in debug(7) level AT+CREG? returns normally....

Thanks again.

-M@

mattb wrote

Do you know why the brackets are around one of the processes?

Sorry, I do not know for sure and cannot check this right now as I'm running GNU/Linux on my Mac Mini and cannot reboot it. Perhaps it means <defunct>, as there usually are no brackets.

Quote

This is the trouble log after a day usage(not heavy).

Somebody was trying to make a call, but it was not a process which was logging to the trouble log. It looks like there was another process running which was using the same modem. As there are answers like CSQ and CREG, this another process must be device handler of smsd.

Probably you have changed some settings and started smsd while there was previous process still running? On OSX, the startup script sms3 should be used to start and stop the smsd, like in any other operating systems too. On OSX there is no init.d directory and therefore install script does not copy the script anywhere. It must be copied and used manually. The script has been tested under OSX and and it works if your uname says Darwin.

What is the version of smsd you are using?

Quote

What is the version of smsd you are using?

Latest 3.1.5

Quote

the startup script sms3 should be used to start and stop the smsd

Previously I was not using the script to start smsd. I have changed that now. Though I am still getting a NO CARRIER error on the logs.

Quote

Somebody was trying to make a call, but it was not a process which was logging to the trouble log. It looks like there was another process running which was using the same modem. As there are answers like CSQ and CREG, this another process must be device handler of smsd.

The two GSM modems are used for the phone system via astricks but are not connected via the serial port, which I use to connect the GSM modem to the MAC for the SMSing. Could this be my problem? Another company handles the phone system so I am unaware of there setup beyond that it uses astericks.

Thanks again.

Modems used should be dedicated for smsd only. Another process which cause "NO CARRIER", may cause serious troubles if this answer is received at the wrong time.

Hey Keke!

Thanks for all your help.

So basically I should have a dedicated GSM gateway for SMSes?

The current setup has astericks running two 2N via the PSTN ports for phone calls. A mac mini is plugged into one of the gateways via a serial port, this is what communicates with SMSD.

I assume that the commands from astericks are colliding with SMSD and causing my problems?

Thanks again. I am but a hack, I made a quick web front end for smsd and thought this would be a easy task....

mattb wrote

So basically I should have a dedicated GSM gateway for SMSes?

Yes, but with low traffic this kind of device can be used.

Quote

I assume that the commands from astericks are colliding with SMSD and causing my problems?

It seems that there was two smsd's running at the same time and that was causing most of problems. As you are now using the sms3 script, there will be no more that kind of problems.

The manual of the device says about serial interface:
"EasyGate’s central processor uses the same interface for establishing calls and so it must have the possibility to block an external serial interface".

And:
"The SMS program is only blocked temporarily during outgoing call establishing and incoming call ringing."

This means that there will be unexpected input sometimes, and sometimes interface cannot be used properly. You can avoid collisions with a longer delaytime in the smsd.conf, for example one minute or more. When an SMS is sent, there can be up to three retries when a collision happens. As you are already handling failed messages, nothing is lost forever.