[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#661698: [smstools] /var/run/smstools/smsd.working not created



> Package: smstools
> Severity: normal
>
> The infofile, which is defined in /etc/default/smstools can't be found here.
> The running process is:
>
> /usr/sbin/smsd -p/var/run/smstools/smsd.pid -i/var/run/smstools/smsd.working -
> usmsd -gdialout
>
> Many thanks, Jan.
> --
> Never write mail to <waja@spamfalle.info>, you have been warned!
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GIT d-- s+: a C+++ UL++++ P+ L+++ E--- W+++ N+++ o++ K++ w--- O M V- PS PE Y++
> PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h---- r+++ y++++
> ------END GEEK CODE BLOCK------

Although this bug is reported long time ago, I try to give an answer, as nowadays new version 3.1.17 of this software
is released.

When this daemon starts, it checks that it can create infofile, if it's defined. If there is any problem with
creation, daemon shows an error message and does not start.

When daemon is running, infofile does not exists all the time.

Infofile is only created when a modem process sees that daemon is going to terminate, but the current sending job is
not completed. Termination signal was received after the sending job of 1 SMS (perhaps containing multiple parts) was
started, and because the signal is "soft" termination, modem process tries to complete the sending. Infofile is used
to tell to the init.d script, that there is still job to do and modem process will stop as soon as the job is
completed. Usually this does not cause delays more than couple of seconds. When I published infofile in the past, the
idea was that the user likely does not want to make current message to be sent only partially, or fail, when daemon is
stopped "smoothly". Kill -9 is used if daemon should stop immediately, regardless of the status of sending.

So if I have understood this bug report correctly, I think that it's not a bug. It's a feature where infofile does not
exist when there is no information to give to the init.d script.

Regards,
Keke


Reply to: