> 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 , y
> Package: smstools
> Version: 3.1.11-1
>
> Hi,
>
> with /tmp mounted "noexec":
>
> 2011-07-28 11:38:21,3, smsd: Exec: startup_check (shell) encountered errors:
> 2011-07-28 11:38:21,3, smsd: ! sh: /tmp/smsd_script.hh5rLQ: Permission denied
> 2011-07-28 11:38:21,2, smsd: Shell /bin/sh testing faile
> Package: smstools
> Version: 3.1.14-1
> Severity: minor
>
>
> Hi,
>
> Smstools currently checks a couple of directories every x seconds.
> That is inefficient:
> 1. it doesn't react immediately on new outgoing sms messages, delaying their
> transmission
> 2. it polls when it is not neccessary,
> I got frusted a bit by this problem (smsd using incredible much cpu
> even when idle) so I ran smsd through valgrind (well, callgrind).
> It looks like tons of time is spend in an usleep(100); (yes, hundred).
> I always thought that Linux would just round it up to the next
> scheduling interval b
> > Package: smstools
> > Version: 3.1-2+lenny1
> > Severity: normal
> > Tags: patch
> >
> > After abnormal termination of modem handlers they chanded zombies.
> > The attached patch would solve the problem.
> > Should also apply to version 3.1.6.
> >
>
> Hi,
>
> thank's for the information.
>
> I
> Package: smstools
> Severity: important
> Version: 3.1.14-1
> Tags: patch
>
> On a monitoring system with otherwie heavy I/O load (due to a large
> number of RRDs being updated on a regular basis), it was noticed that
> sending of a generated SMS was delayed for hours.
>
> Attaching gdb and strac
6 matches
Mail list logo
