Bug 1402521

Summary: [RFE] implement a mechanism in logging subsystem to allow its users to interact with logrotate (automatic "infinite" files maintenance) machinery gracefully
Product: Red Hat Enterprise Linux 7 Reporter: Jan Pokorný [poki] <jpokorny>
Component: libqbAssignee: Christine Caulfield <ccaulfie>
Status: CLOSED WONTFIX QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: ccaulfie, cfeist, cluster-maint, jfriesse, kgaillot, mlisik, phagara
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-14 19:04:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1402523, 1402525    

Description Jan Pokorný [poki] 2016-12-07 18:00:06 UTC
For the problem statement and initial design ideas, see
https://github.com/ClusterLabs/libqb/issues/239

In a nutshell, the top-level goal is to avoid copytruncate option in
logrotate configurations of both corosync and pacemaker (current state)
because, at any rate, any bit missing from logs may be too precious
(e.g. otherwise exactly clarifying the root cause of an issue or putting
an explanation for the observable behavior later in the game, making for
real tough life of anyone trying to inspect past issues) to accept the
connected risk clearly stated in the man page of logrotate (and
logrotate is installed by default so it may definitely kick in).

Currently, most viable implemention would rely on the named pipes:

> libqb will create a named pipe X.pipe for > the target log file X
> which then will be written to per the logrotate > configuration. This
> currently seems the best technical solution:
> 
> - named pipes should be available everywhere we desire
> - custom command in logrotate config would be immediately clear on
>   whether the libqb supporting the signalling mechanism is in use
>   thanks to existing X.pipe file (a la test -p), and thus supporting
>   the sketched fallback scheme for older libqb in use
>   (it could be viceversa: old -> new)

(for the fallback scheme, see below)

> - no sign of "bad polling" (i.e., checking whether inode has changes
>   over and over), just a "good polling" (poll on X.pipe)
> - signal-safe


(signal-safe as opposed to libqb's user having libqb to react on SIGHUP
while handling other signals on its own, with various signal masks,
etc.)

The fallback scheme deals with possible incompatibilities between
libqb's user + its logrotate file vs. libqb version in an actual use:

> One of the possibilities to employ in the updated logrotate files is
> to use firstscript option with custom command to check the libqb
> version (through *.so version info) and if not high enough, to trigger
> logrotate > with an out-of-path original configuration (copytruncate)
> and > subsequently fail to denote the procedure should not continue.

Comment 6 Christine Caulfield 2020-05-18 06:26:56 UTC
Closing it was the right thing to do. An API for closing & reopening log files was added to libqb 2.0, and will be backported to RHEL-8 if needed