Operating system name and version: ubuntu 9.10
Version of smsd: 3.1.6
Smsd installed from: sources
Name and model of a modem / phone: wavecom fastrack
Interface: rs232

Hi,

Is there a file filter on 'outgoing' so only certain files are picked up?

Thanks

In the meantime I have altered extras.c getfile with:

if (strcmp(tmpname +strlen(tmpname) -5, ".LOCK") != 0) { if (strcmp(tmpname +strlen(tmpname) -5, ".smsd") == 0) {

it seems to work...

There is no such kind of a setting available.

If writing of an outgoing file takes more than one second, file should be created into the temporary directory and then moved (not copied) to the outgoing directory. Temporary directory should be located in the same partition as outgoing directory, for example /var/spool/sms/tmp. Also xxx.LOCK files can be created directly into the outgoing directory, but this is problematic if mktemp is used (it does not allow .LOCK at the end of a filename).

Next version of smsd will contain this kind of change:

if (S_ISDIR(statbuf.st_mode) == 0) /* Is this a directory? */ { i = 1; if (strlen(tmpname) >= 5 && !strcmp(tmpname + strlen(tmpname) -5, ".LOCK")) i = 0; else if (!strncmp(tmpname, "LOCKED", 6)) i = 0; if (i) {

With this change a keyword LOCKED can be used in the begin of a filename and smsd will ignore that file.

Thanks Keke

You've raised a good point about the mv since my objective is to run smsd on 2 boxes with a shared 'outgoing' which they can pick up individual messages, and I think a mv from a 'shared' to individual outgoing makes more sense, in which case the filter has to be outside of smsd.

Yes, filtering or load balancing between two servers should be done by the external process. Two or more smsd using the same outgoing directory may cause problems with .LOCK files, and in the case of a conflict, that smsd will log a fatal error and stop abnormally.

I wonder if smsd should have it's own 'processing' directory to eliminate problems with (eg) a shared 'outgoing' but also to protect against any other problems.

ie if processdir is defined, then outgoing is mv to processing directory, which ensures it has sufficient rights & access (especially over NFS/sshfs).

if it chokes on the mv then nothing bad happens, but if it chokes on anything and smsd fails then the last message in 'processing' would be the culprit.

Or reverse it, and if 'shareddirectory' is defined it looks there for new files (possibly with a filter) and mv files individually to 'outgoing'...

Your idea about processdir is good. However, smsd cannot take care about priviledges of files when it's running as an unpriviledged user. And if it's running as a root, there are no problems with priviledges...

Smstools does not have 'processdir' functionality built-in, because usually it's not needed and requirements varies on different environments. In many cases there is a front-end application which selects the smstools server for sending.

In practice, it would be better that smstools server takes it's own messages, rather than messages are given to it. If for some reason one server is not running, other servers will send all messages and nothing is lost.

What do you think about this:

In the global part of smsd.conf, define regular_run = /usr/local/bin/smsd_regular_run.sh and regular_run_interval = 10. Also define outgoing = /var/spool/sms/processdir and create this directory.

The script could collect a list of files in the outgoing directory, and then move those files to the processdir with no error checking and with no error messages. If some another smstools server has already handled some file, it's not a problem. After the script has done it's job, smsd will handle messages from the processdir directory.

Could this fit to your purposes?

Yes, that's a good idea, although I like the 'neatness' of using eventscheduler to get the *next* message - ie after every successful send, mv another message into outgoing and let smsd pick that one up.

The same problem exists though - how to kickstart the first mv - and regular_run would do that, but would it still do it if the modem was broken? I'm not sure if I want to use regular_run to say 'smsd is still working' if the modems are faulty or not.

I kind of think there is a mixed solution hidden here somewhere - if outgoing is empty then regular_run checks 'shared' and mv a single msg, and eventscheduler does the same.

As my other posting, it's all about what happens when things go wrong that I'm most interested in...

Quote

In the global part of smsd.conf, define regular_run = /usr/local/bin/smsd_regular_run.sh and regular_run_interval = 10. Also define outgoing = /var/spool/sms/processdir and create this directory.

I ended up with a compromise - the regular run for the modem can mv every 30 seconds, whilst the global regular run I keep for reporting whether smd is active every 10 mins or so...

Well, perhaps I add regular_run2 and regular_run2_interval for the main process in the next version...

Thanks Keke, but not needed for me - the modem regular_run is ideal since if the modem handler fails then it stops picking up messages from 'shared' and moving them to 'outgoing'.

I am, however, building a list of other suggestions