I'm using SMSTools3 with Cygwin in service mode (cygwinsrv) on Windows Vista. This is the command:

$ cygrunsrv --install smsd --path /usr/local/bin/smsd.exe --type auto --shutdown --env "CYGWIN=server" --env "PATH=/usr/local/bin:/usr/bin:/bin" --desc "SMS Server Tools 3" --args "-t"

The service on Windows starts but hang up immediatly.

In the Services management console the service have the same behaviour. Starts and stop immediatly.

The event viewer says: smsd: PID 7936: service `smsd' failed: signal 11 raised.

Any idea ?

Thanks, Andrea

Smsd v3.1.5beta7

Right now I can see two possibilities for this failure, should check both:

1) If smsd was "tested" before trying to run as a service, there is a /var/log/smsd.log file existing and service cannot open it. Delete the log file and then try to start as a service again.

2) From the 3.1.5beta7 version (thanks for the version information ) there is also shell tested to prevent execution troubles during SMS handling. If a log file was opened successfully, there probably reads somethind like Shell /bin/sh does not exist or is not executable for smsd. chmod 755 /bin/sh to resolve this.

With the first hit the service has started.

But the smsd.log now says:

2009-05-26 20:30:10,2, smsd: Conflict with .LOCK file in the spooler: /var/spool/sms/outgoing/SMS_20090526_203005_13.txt /var/spool/sms/checked
2009-05-26 20:30:10,2, smsd: Fatal error: Cannot move /var/spool/sms/outgoing/SMS_20090526_203005_13.txt to /var/spool/sms/checked. Check file and dir permissions.
2009-05-26 20:30:10,2, smsd: Smsd main program terminated abnormally.
2009-05-26 20:30:10,2, GSM1: Modem handler 0 terminated.

Conflict with .LOCK file means that in the spooler there is already a similar named lockfile. This may be possible is daemon is previously stopped abnormally. Did you have this kind of usage?

Cannot move is caused because smsd was unable to create lockfile (because there was one). I assume that file and dir permissions are good, even when smsd asks to check them.

You could check the .LOCK file, it should contain a process id which created it. From the smsd.log you can see what process id's were running (this depends on smsd version).

However, usual starting procedure in Unix environments, and also in Cygwin if not running as a Windows service, contains .LOCK file checking and removing before daemon gets running.

Global smsd.conf setting keep_filename = no might also help with this kind of environments. This causes that an unique filename is created each time when a message file is moved from directory to another.

the problem persists, smsd.log:

2009-05-27 09:31:04,7, GSM1: Command is sent, waiting for the answer
2009-05-27 09:31:04,2, smsd: Conflict with .LOCK file in the spooler: /var/spool/sms/outgoing/SMS_20090527_093053_14.txt /var/spool/sms/checked
2009-05-27 09:31:04,2, smsd: Fatal error: Cannot move /var/spool/sms/outgoing/SMS_20090527_093053_14.txt to /var/spool/sms/checked. Check file and dir permissions.
2009-05-27 09:31:04,2, smsd: Smsd main program terminated abnormally.
2009-05-27 09:31:04,7, GSM1: <- OK

My smsd.conf:

devices = GSM1
# 1 write all logging to the screen. You can also enter a filename.
# If you remove that line, then the system log daemon (event log) will be used.
logfile = /var/log/smsd.log
loglevel = 7
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
failed = /var/spool/sms/failed
incoming = /var/spool/sms/incoming
sent = /var/spool/sms/sent
mypath = /usr/local/bin
os_cygwin = yes
keep_filename = no
eventhandler = /usr/local/bin/mysmsd
autosplit = yes
receive_before_send = yes

[GSM1]
device = /dev/com13
smsc = 393492000200
#memory_start = 0
#check_memory_method = 3
mode = new
incoming = high
cs_convert = yes
report = no

I solved by setting the account of the Windows Service equal to the account with whom I logged in Windows Vista.

The default account: Local System causes these problems.

Andrea

Fine, and changing account is also the best solution. Another workaround is setting all spool directories world-writable.

Smsd failed to detect this permission problem during startup check, because check creates test files using 600 (directory is 755). Later smsd creates files using 666 in Cygwin, and fails.

I fix this startup check issue in the next version.

Thanks for the information.

I am glad to be helpful...

SMSTools3 is a great software !

Andrea