Operating system name and version: Suse Linux Enterprise Server 11.2
Version of smsd: 3.1.14
Smsd installed from: sources
Name and model of a modem / phone: Siemens TC35i
Interface: serial

Hello,

I use smstools3 to send notifications from Nagios.

Every few days, the smstools3 hangs up und the load on the server goes high. I can`t restart the service or kill the process smsd. The only thing, that solve the problem is to reboot the server.

If the problem appears, I have seen that the process smsd is hanging in process state "D".

To exclude the hardware, i have change the gsm-modem and serial cable. I have used instead of the serial port a USB-to-Serial Adapter to connect the modem.
Nothing will solve the problem.

Everybody here, who has a solution or idea for my problem?

Thanks in advance!

I have not seen this kind of problem before. Sorry to say, but I do not know what causes the problem, and how to fix it.

With a fast googling it seems that some bug in the device driver or kernel may cause this problem. Process has gone to state "uninterruptible sleep", and nothing can be done (nothing else than reboot). As this happens every few days, smsd process still works without this problem between those "few days". Is your setup also receiving messages? If it is, it means that incoming messages are checked periodically, 10 seconds by default, and this causes traffic to the serial interface, which usually works.

The only thing I can currently imagine to try, is the way how serial interface is handled by smsd. After the version 3.1.9 (released 17.06.2010), by default the select() function is used for handshaking. Previously ioclt() was used. To see if this has any difference, use a modem setting send_handshake_select = no.

Thank you, for your quick answer.

I have edit the config for the parameter send_handshake_select = no.
But the problem appears again.

I use smstools3 only for sending sms, receiving sms is disabled.

Do you have another idea?

As receiving is disabled, modem is initialized once when smsd is started, but after this smsd talks with a modem only when a message is tried to send. How often your system sends messages, and can it send any messages properly?

After changing the configuration, you of course restarted smsd, right?

I have send test sms`s via cli to test it.
I receive the sms´s and can't see any error in the log.
The failure suddenly appears during work off the sms queue.

It may be that i can send 50 sms and more and all seems good.
And one day later the smsd is stuck in state D.

Yes, i have reboot the server to be sure that the config is enabled.

You could try with a modem setting keep_open = no, but probably it will not help. This setting means that serial port is open only when smsd is sending or receiving messages, idle time the port is closed. If you send many SMS at a time, the port is kept open and the setting makes no difference.

One more thing: which smsd process is in state D, main process or modem handler? I was assuming that modem handler, and at least not both of processes. But if it's mainprocess, modem has nothing to do with it. In the case of state D, what is in the outgoing and checked directories? And what is in the log, especially when running with loglevel = 7?

Both processes stuck in state D. I can kill no one of this.
Generally i run smsd in loglevel 7 but the log display no errors or other failure.

The last entry is mostly that sendings sms and delete the "sms file" is OK.

As you have installed smsd from sources, try the following:

In the smstools3/src directory, edit the file locking.c. Find "sync()", which is used once:



Change the code to:



After sync(); call is removed, and fsync(lockfile); is done before close(lockfile); is called, only one file is synchronized, not the whole system if running smsd as a root. I'm not sure if this caused problem in your system, but currently I have no any other idea.

Save the file, make clean smsd and cp -p smsd $(which smsd). Restart smsd, and look forward if the problem still remains, or if it seems to be gone...

Sorry, for my late answer.
I want to be sure, that the problem is solved.

I edit the source code based on your proposol and now the problem is fixed.
The process runs since 1,5 week.

But I don`t unterstand why the copy command triggered this failure.

Thank you!