I also tried to use smsd as daemon but it got stuck and didn't work as well.

I am working on a Debian GNU/Linux system, release wheezy/sid, kernel: Linux 3.2.0-3-amd64
I downloaded smstools3-3.1.14.tar.gz and debugged it:

(gdb) r
Starting program: /usr/local/bin/smsd -s

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7895ada in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0 0x00007ffff7895ada in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff78bc472 in vsnprintf () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff789e2c3 in snprintf () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00000000004193a7 in lockfile ()
#4 0x00000000004160a0 in movefilewithdestlock_new ()
#5 0x00000000004076aa in mainspooler () at smsd.c:1749
#6 0x000000000041593d in main (argc=2, argv=0x7fffffffebf at smsd.c:6911
(gdb)

Finally I found some kind of solution, though it's more a guess than
really understanding how the programm works:

diff smsd.c smsd.c~
6910c6910
< process_id=0;
---
> process_id=-1;

smstools is working so far now.

I got the same error.
When process_id == -1 (main process), then DEVICE.name become devices[-1].name at src/locking.c:45. Negative index cause memory access violation and result in SIGSEGV. I propose more reliable patch:

--- a/smstools/src/locking.c +++ b/smstools/src/locking.c @@ -42,7 +42,7 @@ int lockfile( char* filename) lockfile=open(lockfilename,O_CREAT|O_EXCL|O_WRONLY,0644); if (lockfile>=0) { - snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), DEVICE.name); + snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), (process_id != -1) ? DEVICE.name : "MAIN" ); write(lockfile, pid, strlen(pid)); close(lockfile); sync();

Just for the record, there has already been a topic about this bug. Here is the link http://smstools3.kekekasvi.com/topic.php?id=831.

3.1.15 with a fix is now released.

Thank's unterwulf, crux and others, and sorry for the delay.