Operating system name and version: Windows XP SP3
Version of smsd: 3.1.14
Smsd installed from: sources
Name and model of a modem / phone: Siemens MC 35
Interface: serial

After upgrading from 3.0.10 to 3.1.14 I have noticed the following strange behavior of smsd.

Setup : one of com ports is free of modem ( modem is not connected ). However it is specified in conf file.

How it worked in v. 3.0.10 :
In log I saw messages like "Modem is not clear to send".. During shutdown of smsd service, such modem process has been killed successfully.

How it works now in v. 3.1.14 : In log at startup
2011-02-08 02:01:29,5, M5: Modem handler 8 has started. PID: 3060. 2011-02-08 02:01:29,5, M5: Using check_memory_method 1: CPMS is used. 2011-02-08 02:01:29,6, M5: Checking device for incoming SMS 2011-02-08 02:01:29,6, M5: Checking if modem is ready

After that, there is nothing in log regarding this modem.?!
Moreover , During shutdown of smsd service, such modem process remains not closed.
I don't understand , why ?
Is there something wrong with my setup?

Below is my conf file :

Your setup is correct. But it's not very usual that empty port is used in the production...

After the version 3.1.9, handshake is using a different method than before. It's using select(), which is widely used today in many applications. It seems that this call hangs on Cygwin, when modem is not connected to the port.

If you want to, you can move back to the previous method with a modem setting send_handshake_select = no. But you will get lot of error messages if using an empty port...

Hi keke, thank you for information

send_handshake_select = no

doesn't help to terminate previously mentioned modem processes at shutdown of smsd.

May be some other setting are playing role here ?

Okay, I checked this on XP, and with device = /dev/com1, with no modem connected, there of course was errors but no problem with shutdown. Smsd was using send_handshake_select, as it is a default.

I then tried with a setting device = /dev/coM1. Logging stopped like yours, and the process does not disappear even with kill -9...

I do not understand why you other (connected) modems works, for example the first one with device = /dev/coM1. But anyways, change your modem names to lowercase, or use separate definitions for devices.

Thanks a lot, keke !

So , overall solution is

1) use modem setting : send_handshake_select = no
2) port definitions should not contain uppercase letters

No, there is no reason to disable send_handshake_select. In most cases it works better than older method. Because of this, it's used by default.

In Unix like operating system filenames are case-sensitive. Can you confirm that other modems worked well, even with "coM" setting? Just asking because it sounds strange...

1) There were no connected modems during my testing. only empty ports. so I can't confirm proper operation with upper case letters in com port definitions.

2) I checked that send_handshake_select = no is mandatory condition to terminate modem processes with empty ports during smsd shutdown. Without this setting stopping smsd does not stop these processes.

I cannot see send_handshake_select = no as a general instruction for Cygwin. Just tried with send_handshake_select enabled, with /dev/com1 with no modem connected, and after some "put_command expected..." log messages, I killed the mainprocess with sigterm. As expected, it sent signal to the modem process which stopped, and after this the main process stopped.

In your case, if the logging freezed as it freezed with coM setting, it may be possible that handshake signals of the port were in bad condition, and therefore select() function freezed. However, those signals should have affect to older method too, when rtscts is not disabled.

Before you started the latest test, was there any older modem process of smsd in the process list? If there was, carefully check what new processes (PID numbers) are started, and what are stopped when the main process is killed.

Hi keke,

Yes , I confirm that no old processes were available before I started last test.
Today I repeated my testing with same result: only specifying send_handshake_select = no allows for main process to terminate modem processes with empty port.

I see only one difference in your and my tests: I have started and stopped smsd as windows service.

I too repeated testing and now as a Windows service, and using Windows UI...

device = /dev/com1
send_handshake_select = no
--> Starts and stops normally.

device = /dev/com1
send_handshake_select = yes
--> Starts and stops normally. Nothing difference.

device = /dev/coM1
send_handshake_select = no
--> Modem process freezes and cannot be stopped.

When in your case send_handshake_select makes a difference, just use the setting. You probably have different version of Cygwin than I have.

Luckily you now have at least one modem, so you do not need to test with empty serial ports . For testing there is also a modem setting modem_disabled = yes available. When this setting is used, a device can be a dummy file, like /tmp/com1.

Hi Keke,

I repeated testing again.
Even if I specify option exactly :

devices = m* 1-3 ... [m1] device = /dev/com1 send_handshake_select = yes

modem process does't stop.

my Cygwin version = 1.90.4.1

My worry is not about testing. But about production. Hardware environment tends to change from time to time. In this case somebody can forget to edit conf file properly. This way some processes will be in memory after restarting of smsd. Not good situation.

My previous test was done with "CYGWIN_NT-5.1 wxp 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin".

I then removed whole Cygwin and made a fresh install with the latest version: "CYGWIN_NT-5.1 wxp 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin". Tested from command line and from Management Console, and in both cases smsd stopped properly, even when send_hanshake_select was used.

There is no Cygwin 1.90.4.1 existing. Perhaps your system is something else than Cygwin? Anyways, smsd does not cause the problem. In your case it is caused by the system, where select() function does not work properly. I cannot help with this.

It does not sound very good, if the hardware in your production system tends to change from time to time. But in any case, if anyone makes any changes to the system or to the setup, those changes of course should be tested carefully, to prevent any bad situations.