Bug#755898: smstools: Great delays before messages are processed
> 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 strace to the stalled daemon revealed that it was
> stuck in a sync(2) call.
>
> Investigation of the source code showed that smsd makes frequent use of
> lock files as part of operations that involve reading from spool files
> and moving files around in its spool directories. After creating lock
> files, sync(2) is called which causes the kernel to write buffered file
> metadata modifications *for all filesystems*. This can have significatnt
> negative effects on overall filesystem performance.
>
> Lock files have no use after a system reboot and there seems to be no
> other part of smstools that is interested in the lock files' contents,
> therefore it is unclear why "sync" operation is needed at all. Even if
> it was important to preserve the lock file contents across system
> crashes, fsync(2) or fdatasync(2) would be the right calls to use.
>
> I suggest simply removing the sync() call from lockfile() in
> src/locking.c (that's why I set the "patch" tag.)
>
> As a quick and easy workaround here we have overridden the sync(2) call
> on the affected system by running smsd with the eatmydata shared library
> preloaded. This has solved our latency issue.
>
> Cheers,
> -Hilko
This bug is fixed in the version >= 3.1.16 (upstream).
Regards,
Keke
Reply to: