[ClusterLabs] Pacemaker detail log directory permissions

[Jan Pokorný]

On 29/04/19 14:58 +0200, Jan Pokorný wrote:
> On 29/04/19 08:20 +0200, Ulrich Windl wrote:
>>>>> Jan Pokorný <jpokorny at redhat.com> schrieb am 25.04.2019 um 18:49
>>>>> in Nachricht <20190425164946.GF23995 at redhat.com>:
>>> I think the prime and foremost use case is that half of the actual
>>> pacemaker daemons run as hacluster:haclient themselves, and it's
>>> preferred for them to be not completely muted about what they do,
>>> correct? :‑)
>> 
>> I interesting aspect: So the commands write directly to one file
>> concurrently?  How's synchronization done. It's especially
>> interesting with multiple threads.
> 
> You don't believe your libc (fprintf in particular) to abide the
> POSIX constraints, do you? :-)
> 
>>   All functions that reference (FILE *) objects, except those with
>>   names ending in _unlocked, shall behave as if they use flockfile()
>>   and funlockfile() internally to obtain ownership of these (FILE *)
>>   objects.
> 
> [https://pubs.opengroup.org/onlinepubs/9699919799/functions/flockfile.html]
> 
>> Wouldn't it be much easier to use some socket-bases syslog like
>> service that serializes all the messages to one file. Then the
>> clients just need write access to the socket, not to the files.

FWIW, have just realized that by virtue of this, we have actually
silently alleviated a hidden lock contention (against the realtime
corosync process! but allegedly, it is not too verbose if nothing
interesting happens unless set to be more verbose) since
Pacemaker-2.0.0:

https://github.com/ClusterLabs/pacemaker/commit/b8075c86d35f3d37b0cbac86a8c90f1ac1091c33

Great!

But we can do better for those who would prefer to serialize
multiple (per daemon) file outputs by hand (if ever at all, complete
serialization can be found in the syslog sink, perhaps) as briefly
touched on earlier in this thread[1].

[1] https://lists.clusterlabs.org/pipermail/users/2019-April/025709.html

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190429/8e0476a1/attachment-0001.sig>