Operating system name and version: CentOS 5.5
Version of smsd: 3.1.14
Smsd installed from: sources
Name and model of a modem / phone: Wavecom Fast GO Plus
Interface: serial

I seem to see a problem where my regular_run script is not running when registration is lost and I get a lot of:

2011-02-10 11:59:44,5, WAVECOM: MODEM IS NOT REGISTERED, WAITING 1 SEC. BEFORE RETRYING 99. TIME
2011-02-10 11:59:46,5, WAVECOM: Signal Strength Indicator: not present of not measurable, Bit Error Rate: not known or not detectable

I expect these lines to pause when regular_run runs because regular run takes ownership of the modem?

Thanks,

Matt

Regular_run is not executed when registration is lost and smsd tries go back to the network. Registration is the most important thing, and in this case it will override all other functions. Also, in many cases, if the modem is not registered, regular_run (for a modem) will not work properly.

Perhaps I have missed your point. In this case please explain what kind or regular_run you do have, and how it should work in your environment. And how often registration is lost, is it a seriously repeated problem?

Ah, that explains it. I couldn't see that from reading the docs. I presumed smstools always halts to run regular_run at the specified interval.

I was using regular_run to reset a modem if creg? returns 0,2. This is because a modem I have only tries for two minutes to gain network registration. After this period it just sits there! :-S

So I used regular_run to check creg? and then issue a reset if network registration was lost.

I could use the alarmhandler, but I believe this will clash with smsdtools trying to access the modem. I could do with either smstools issuing the reset for me, but only on loss of network registration. Or a way to get sole access to the modem from a script.

Okay, now I understand...

Generally taken regular_run is not good for monitoring purposes, as it is not called when smsd has something more important to do. However, it is executed after the initialization of modem has failed. In this case the alarmhandler could create a "flag file" which indicates that reset is required. Some external process, or regular_run could then see that reset is required, and perform it. Alarmhandler cannot do this, because the modem is in use.

Here is how I do this in some environment:



External task will see the file, and it stops the smsd, resets modems (using hardware) and starts smsd again.