Sms version 3.0.10

it works very fine but it sents each message 2 times.

It don't create the "sending" file message 2 times, it creates only one instance but sent it 2 time.

I don't see the double trasmission in my sql log with 2 equal records, but each records have msg_id field step by 2, 98-100-102 and so.

Initially I don't give my attention, but the telco operatos bill shows all sent messages duplicated.

Anyone can help me.

Tnx Carlo

This sounds like there is one retry for each message. I cannot guess the reason without the logfile.

With loglevel = 7, show a piece of smsd.log here. Use Private tag to protect the data (see this post for details).

What is needed to see, is everything after the line containing "I have to send..." until a message is sent. If there are different response codes for other messages, it's useful to see them too. More log is better than less log .

keke wrote

This sounds like there is one retry for each message. I cannot guess the reason without the logfile.

With loglevel = 7, show a piece of smsd.log here. Use Private tag to protect the data (see this post for details).

I'm not a Linux guru what means and how to set the log level to 7?

Tnx Carlo

In the global section (start of the file) of smsd.conf, define loglevel = 7. Restart the daemon and you will get a file /var/log/smsd.log containing a detailed information about the communication. After couple of messages are sent, show the smsd.log here.

I think to have find the problem, I generated to long msg text, about 250 chr, and so its are splitted into 2 .


I'm observing too close the log, if I'll find more problem I write here.



Another question; into "checked" there are 2 file same name both one with the LOCK added to tail.

SMStools don't can move it to send folder and so closed execution.

Is there a manner to check if SMStools stopped and restart it byself?

Ciao Carlo

hamradio wrote

I think to have find the problem, I generated to long msg text, about 250 chr, and so its are splitted into 2 .

I'm observing too close the log, if I'll find more problem I write here.

If there was no any error messages (and retries) in the smsd.log, you surely have been sending multipart messages in the past too.

If you can upgrade smsd to 3.1.5, you will have more detailed information in the log file. If a message contains more than one part, there will be a notification like Part 1 / 3 when starting to send each part.

hamradio wrote

Another question; into "checked" there are 2 file same name both one with the LOCK added to tail.

SMStools don't can move it to send folder and so closed execution.

Is there a manner to check if SMStools stopped and restart it byself?

Smsd does not restart by itself.

There can be .LOCK files if smsd was killed incorrectly, usually with SIGKILL. Smsd should always be started and stopped using init.d/sms3 script. This script uses SIGTERM and when smsd receives a termination signal, all started jobs are completed before terminating.

When the smsd starts, it performs a startup check. Within this check, all .LOCK files are removed. If there are any troubles while removing those files, error message is written to the log.

Are you running smsd as an unpriviledged user? Probably there is a permission problem. Who owns those .LOCK files?

keke wrote

Are you running smsd as an unpriviledged user? Probably there is a permission problem. Who owns those .LOCK files?

If I run ps aux I have 2 statement for SMSD and for boths the 1st column is = smsd.


About lock file

Group = dialout
User = smsd.

I have not many sms traffic because SMStools is applied into a geographic Wifi networks authentication software, and actually I haven't nont many owners.

Ciao Carlo

Just checked again, smsd version 3.0.10 will find .LOCK files and will try to remove them when a daemon is starting. If there are any .LOCK files which cannot be removed, there will be an error message in the smsd.log. Have you checked this, is there a message?

Yes, I see it in the log and delete both files manually, and manually I resent the sms msg.

Now SMStools is running.

Carlo

Okay, but this issue is strange...

You are running a daemon as an user smsd and the .LOCK file was owned by smsd:dialout. And the startup check was unable to remove this file. The format of error message is: "Cannot unlink file <filename>: <reason>". What has been the reason?

What GNU/Linux you are running and from where the smsd is installed (from the package repository or from the sources)?

keke wrote

You are running a daemon as an user smsd and the .LOCK file was owned by smsd:dialout. And the startup check was unable to remove this file. The format of error message is: "Cannot unlink file <filename>: <reason>". What has been the reason?

The lock issue appeared when I copy by winscp the sent file to my pc running XP, and after I copy this file to outgoing into server I assigneg a chmod=777.

I must do it because a owners claims because he don't receive my sms with username e password, but it's sent. Sometimes sms from Italy to CH or DE are missed, I sent its by Wind.

Quote

What GNU/Linux you are running and from where the smsd is installed (from the package repository or from the sources)?

An istance of Ubuntu 8.0.4 running under Proxmox Enviroment.

hamradio wrote

keke wrote

You are running a daemon as an user smsd and the .LOCK file was owned by smsd:dialout. And the startup check was unable to remove this file. The format of error message is: "Cannot unlink file <filename>: <reason>". What has been the reason?

The lock issue appeared when I copy by winscp the sent file to my pc running XP, and after I copy this file to outgoing into server I assigneg a chmod=777.

You did see an error message about the .LOCK file in the smsd.log, right? It was Cannot unlink file filename.LOCK: reason. What was the reason?

I assume that you had this problem once, but it's not repeated. This is because all files in the checked folder are created by the smsd itself. You should never put any files to the checked folder by yourself.

hamradio wrote

SMStools don't can move it to send folder and so closed execution.

I think that this is not what has happened. You should see some error messages in the smsd.log if there are any troubles with handling of files. The file .LOCK was created by the smsd mainspooler process and therefore smsd should be able to remove it too. There can be .LOCK files left if smsd is killed incorrectly, using kill -9, which should not be done. There is sms3 script available (named as /init.d/smstools in Ubuntu), always use this script to start and stop the smsd.

If you still have this problem active, please provide some more details and information.