Operating system name and version: Debian lenny kernel: 2.6.26-2-686
Version of smsd: 3.1.11
Smsd installed from: Debian lenny-backports repository
Name and model of a modem / phone: Sierra Wireless Compass 889
Interface: USB

Smstools doesn't properly call alarm handler in my case.

I use the alarm handler to create a file that is checked by another script (this then kicks smstools among other things to try and resend a failed message). The scripts shouldn't be the problem though as they're not called at all. And they did work on another machine running the same setup but 2.6.26-2-486 kernel.

I actually had the same problem on another installation (with the 486 kernel) too, but it resolved itself when I re-installed the OS (to test some other stuff). So I figured I had something weird in my installation, but now this haunts me again.

Any ideas? Would love to use the alarm handler as it worked so flawlessly before.

I do not yet have any good ideas...

As you are running 3.1.11, the execution of external commands was working when smsd was started. Therefore alarmhandler should work too.

What is in the smsd.log when using loglevel = 7 and alarm is created? In my case there is:

2010-09-02 14:25:51,7, GSM1: Running alarmhandler: /usr/local/bin/smsd_alarmevent ALARM 2010-09-02 14:25:51 3 GSM1 "Modem did not accept the init string"
2010-09-02 14:25:51,7, GSM1: Done: alarmhandler, execution time 0 sec., status: 0 (0)

Are you using an eventhandler, and does it have this same issue too?

There's no mention of running alarmhandler in the log.

Just "write_to_modem: device busy, waiting" and then "Moved file /var/spool/sms/outgoing/something to /var/spool/sms/checked". Sorry I can't get the actual log here now.

That output comes after the modem state has been checked "Checking if modem is ready -> AT". The modem is busy, yes, the machine uses it as the primary link to the internet. But that's where the alarmhandler and my other script should come in.

I haven't put up any eventhandlers of my own.

Can you check what is the alarmlevel setting in your current smsd.conf?

Assuming that it's missing, a default level WARNING is used. When a transmitter is busy, alarmhandler is called with DEBUG level, and therefore the script is not executed. This level was selected, because usually it's not a big problem if the transmitter is busy, it's just handshaking.

But if you have the setting alarmlevel = DEBUG or alarmlevel = 7, I have to examine this issue little bit more...

Haa! Thanks. It seems to be working correctly with alarmlevel = DEBUG. Maybe I had the alarmlevel set to something else than the default as a test but forgot to actually make the change later on. Does the DEBUG level take care of all the other alarms too? If some day in the future it throws something else than the "write_to_modem" error.

On a side note, this required me to reboot as the debian-provided /etc/init.d/smstools script seems to be buggy and didn't want to restart smsd.

But anyway, I'm a happy smstools user now

kuula wrote

Does the DEBUG level take care of all the other alarms too? If some day in the future it throws something else than the "write_to_modem" error.

The DEBUG level will catch all alarms, in the future too.

kuula wrote

On a side note, this required me to reboot as the debian-provided /etc/init.d/smstools script seems to be buggy and didn't want to restart smsd.

I do not know very much about that script, it's based on my script but strongly modified by the package maintainer on Debian. Perhaps you could describe and reports bugs to Debian?

There is also original script sms3 available, it can be used on all systems.

kuula wrote

But anyway, I'm a happy smstools user now

Great, and thanks for choosing this software