examples/tests: make qb logging dispose the memory
A.k.a. "be a good example of using this very library".
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>
Using years-old benchmark attached to PostreSQL ML[1], I've observed
tiny bit more than double boost in speed when using fdatasync instead of
traditional fsync, on two Linux machines, each equipped with an SSD.
While the observation may be disputable (there are various
interpretations to what "synchronized I/O" actually means), by logical
extension of what the two are supposed to do, one can expect fdatasync
will perform no worse than fsync. Having the timestamps correct is
really not a priority, compared to timely processing of the message
stream. So let's use it whenever possible with QB_LOG_CONF_FILE_SYNC
requested.
As an aside, PostreSQL seems to be be using "fdatasync" method of
updating out to disk by default on Linux till today[2].
[1] https://www.postgresql.org/message-id/1095055866.414539fadb90d@webmail.rawbw.comhttps://www.postgresql.org/message-id/attachment/20659/syncbench.c
[2] https://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-SYNC-METHOD
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* Fix typo: occur{ -> r}(ed|ing)
* doc: qb-blackbox(8): cosmetic touches
* doc: qb-blackbox(8): add "Portability notes" subsection
* Low: build: git-ignore build-aux/release.mk "overhead" files
This should have been part of ae5138d.
* build: release.mk: ensure checksum file generated even w/o signing
This should have been part of d20e48a.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* Low: log: prevent static vs. implicit non-static declaration clash
...of qb_log_callsites_dump_sect, that could happen when its usage
in qb_log_callsites_register was uncommented.
* Low: tests: fix duplicate "const" declaration specifier
This is a follow-up for d69cc7b (making the pointer itself constant was
meant as a self-defense, no-overwrite measure).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* Fix typo: p{rr -> r}ocess
* doc: qbrb.h: several fixes to punctuation
* doc: qbrb.h: reindent example writer's error label as per reader
* doc: qbhdb.h: explain former importance to libqb itself
* doc: ipcc.c: explain why client would timebox recv from server
Also refer to commit d633b4e.
* doc: qblog.h: minor stylistic/doxygen markup cosmetics
* doc: qblog.h: note qb_log_format_set vs. fork interaction wrt. PIDs
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
The default goal line now serves mainly the documentation purpose,
otherwise it could be squashed down to "sign" target.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
It also means the missing key specification is now a hard error when
ASCII armored files are to be created (directly or by other rules).
Leveraging the previous commit, it is now unnecessary to guard against
release mode not being requested, so this guard is dropped completely
in the transition, allowing for the full-fledged (incl. GPG signing)
release delivery testing without mangling with in-tree tags.
To allow "sign" target to (possibly eventually) become the implicit goal
even if "gpgsignkey" variable is explicitly unspecified, make it depend
on "tarballs".
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Previously, generating custom versioned tarballs without requiring
a "release" (which comprises also tagging hence in turn making the
implied version match the required one as desired) would not allow
to test the release routines thoroughly incl. GPG signing.
Unfortunately, allowing for a temporary tag is prone to accidentally
slipping it to the distributed tree, so that should rather be avoided.
Now it can.
Another step to blur the boundaries between whether "release" is
specified or not is make checksums file generated unconditionally.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Pattern matching is a brilliant DRY technique in makefile's composition,
so it would be a pity to miss such a nonconflicting application related
to the previous, "sign tarballs" commit.
For that to work reliably for the complete dependency backtrack, though,
a pre-existing issue with parallelized work on the prerequisites needs
to be fixed first. The problem was "tarballs" (phony) target missing
in the linearized supply chain for the signed tarballs, as opposed to
to supply chain for the checksums file that can be worked on in an
(unordered!) interleave with the work on these signed tarballs.
Hence fix this race condition by stretching "tarballs" target as
progress barrier (using it as a prerequisite) uniformly for all the
deliverables that are going to be signed (used to be just for "sha256"
target)). And when at it, make "deliverables" variable list them
conveniently (along with reformatting definitions of other variables
for uniformity).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
The instances of the former in a private static variable name, the
latter in the comment to an internal-use-only function-like construct.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
Various "configure" commits by wferi recently introduced new
compat/custom m4 macro files in m4 directory, which itself was,
so far, assumed ephemeral (not strictly needed for reproducing
the build successfully, i.e., bits that can be completely purged
when cutting down the project files to the bone). Apparently,
this assumption no longer holds so several places need to be
adapted.
Amonst others, m4 directory no longer needs to be reinsured in
autogen.sh, and special care must be taken with .gitignore
and maintainer-clean-local target of the main Makafile.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* memleak: ipc_socket: properly dispose local-scoped strndup values
Leaking memory was only possible when using filesystem sockets (see
use_filesystem_sockets function) and either:
- client is deliberately disconnecting from a server (continued run
imposes a risk of exhausting memory)
- server is deliberately disconnecting from its client (ditto, but
more substantial risk due to the common shared-resource nature
of the server)
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* memleak: ipc_socket: properly dispose inter-function strdup values
Leaking memory was only possible when the server accepted the client,
but didn't get (or was too shy) to talk to it prior to proceeding with
a disconnect.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* ipc_socket: care to explain what's going on with file name inference
Related to the code parts at hand, there was an investigation/fix in
the past, initiated by "make check" failure on FreeBSD 9 [rhbz#1256701].
Unfortunately, not only the magic constant being modified was not
explained in 1908e6c, but (one can derive because of a lack of solid
background of what's going on here, which might have caused that),
it was modified incorrectly at one instance (see also [PR165 comment]),
which was then reinstated in 7ebcb3d.
So, finally de-mystify those magic constants. Also break the symmetry
between the client/server further with depending on the canonical
"request socket" alias at the server side (the former worked equally but
it was unnecessarily confusing and there's a risk this artificial alias
will get removed in the future).
[rhbz#1256701] https://bugzilla.redhat.com/1256701
[PR165 comment] https://github.com/ClusterLabs/libqb/issues/165#issuecomment-142949541
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
It was not clear to non-native English speakers.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed by: Jan Pokorný <jpokorny@redhat.com>
* IPC: Allow filesystem sockets to be chosen at run-time on Linux
Most of this patch came from Andrew Beekhof.
Keep a global variable that decides whether or not to use filesystem sockets
or abstract sockets for IPC connections. This variable is set by the presence of a file (default /etc/libqb/force-filesystem-sockets).
* tests: Fix test_ipcc_truncate_when_unlink_fails_shm test using FS sockets
When using filesystem sockets, the
test_ipcc_truncate_when_unlink_fails_shm test always fails, this was
because the unlink() call is wrapped to fail and so it never cleans up
the old version of the socket.
The fix is to preemptively remove the file before unlink gets wrapped.
* doc: Explain the force-filesystem-sockets option
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
The sockets are named using a random() suffix in at attempt to isolate
concurrent test. However random() always returns the same random number
by design ... unless pre-seeded with some value being unique enough for
the particular execution.
Borrowing the most of the above message from original "srandom" fix by
Chrissie who also discovered this issue (nice!), I thought it would be
more viable if we encoded such "unique enough" variables directly to
IPC name being generated, not relying on pseudorandom generators in any
way. Hence this other fix.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
qb_loop_signal_add() used to set any signals it wasn't managing
back to SIG_DFL. This is unfriendly behaviour in a library.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Reviewed-by: Jan Pokorný <jpokorny@redhat.com>
This should prevent libqb from looping in the server if the
ringbuffer gets corrupted. Instead the client will be disconnected.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
The intention behind enabling the syslog tests on demand (642f74d) was
to tread cautiously as libtool used to alert that something controversial
is going on:
$ ./autogen.sh && ./configure --enable-syslog-tests && make check
> ...
> *** Warning: Linking the executable log.test against the loadable module
> *** _syslog_override.so is not portable!
> ...
owing to the fact that _syslog_override.so is being linked (through
libtool) with LDFLAGS=-module.
In fact, the issue did go away with a fix to the "make install" process
(ebcff54) for which _syslog_override.so* files were being picked
undesirably prior to the fix, which manifested itself also on
"make rpm" (hence the respective commit message):
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/lib64/_syslog_override.so
> /usr/lib64/_syslog_override.so.0
> /usr/lib64/_syslog_override.so.0.0.0
The explanation for the secondary positive effect on the mentioned
libtool's warning going away is rather simple:
"lib" prefix switches the expectations about the result as a library
(also due to "libdir" destination) rather than as an executable object.
Change like that ensures the result is what libtool's manual calls
"dynamic module that can be opened by lt_dlopen" rather than "runtime
library that cannot" in the context of Mac OS X, which was likely the
cause of the portability warning.
(https://www.gnu.org/software/libtool/manual/libtool.html#FOOT10)
And because the tests themselves are run through the libtool wrapper
scripts capable of relinking and other magic
What libtool manual has to say on this topic:
> Note that libtool modules don’t need to have a "lib" prefix. However,
> Automake 1.4 or higher is required to build such modules.
referring to version released 15+ years back, which is assumed anyway.
(https://www.gnu.org/software/libtool/manual/libtool.html#Modules-for-libltdl)
* * *
That being said, there's now no longer a reason to have "syslog-tests"
enablement conditionalized (no longer supposed intrusive), hence enable
them unconditionally along the other libcheck-based tests
-- whenever libcheck is detected.
This changeset also drops any trace of --enable-syslog-tests switch
in various places using that (spec file, Travis CI configuration)
making for a complete vaporizatio of this choice.
This reduces overlinking of qb-blackbox. Being a seldom used executable,
the gains are mostly theoretical, but at least this silences warnings
from some QA tools.
