[ClusterLabs] changing pacemaker.log location

Andrew Beekhof abeekhof at redhat.com
Tue Aug 16 22:04:05 UTC 2016


That shouldn't be true.
Pacemaker itself has ~6 processes all writing to it without issue.

We're all appending so there shouldn't be a problem having multiple
processes writing to the same file.
Have you seen logs be lost?


On Mon, Aug 15, 2016 at 4:47 PM, Jan Friesse <jfriesse at redhat.com> wrote:
> Ken Gaillot napsal(a):
>
>> On 08/12/2016 10:19 AM, Christopher Harvey wrote:
>>>
>>> I'm surprised I'm having such a hard time figuring this out on my own.
>>> I'm running pacemaker 1.1.13 and corosync-2.3.4 and want to change the
>>> location of pacemaker.log.
>>>
>>> By default it is located in /var/log.
>>>
>>> I looked in corosync.c and found the following lines:
>>>          get_config_opt(config, local_handle, KEY_PREFIX "to_logfile",
>>>          &logfile_enabled, "on");
>>>          get_config_opt(config, local_handle, KEY_PREFIX "logfile",
>>>          &logfile, "/var/log/pacemaker.log");
>>> in mcp_read_config
>>>
>>> I can't find any other documentation.
>>>
>>> Here is my corosync.conf file.
>>>
>>> totem {
>>>    version: 2
>>>    # Need a cluster name for now:
>>>    #   https://github.com/corosync/corosync/issues/137
>>>    cluster_name: temp
>>>    crypto_cipher: aes256
>>>    crypto_hash: sha512
>>>
>>>    interface {
>>>      ringnumber: 0
>>>      bindnetaddr: 192.168.132.10
>>>      mcastport: 5405
>>>    }
>>>    transport: udpu
>>>    heartbeat_failures_allowed: 3
>>> }
>>>
>>> nodelist {
>>>    node {
>>>      ring0_addr: 192.168.132.25
>>>      nodeid: 1
>>>      name: a
>>>    }
>>>
>>>    node {
>>>      ring0_addr: 192.168.132.21
>>>      nodeid: 2
>>>      name: b
>>>    }
>>>
>>>    node {
>>>      ring0_addr: 192.168.132.10
>>>      nodeid: 3
>>>      name: c
>>>    }
>>> }
>>>
>>> logging {
>>>    # Log the source file and line where messages are being
>>>    # generated. When in doubt, leave off. Potentially useful for
>>>    # debugging.
>>>    fileline: on
>>>    # Log to standard error. When in doubt, set to no. Useful when
>>>    # running in the foreground (when invoking 'corosync -f')
>>>    to_stderr: no
>>>    # Log to a log file. When set to 'no', the 'logfile' option
>>>    # must not be set.
>>>    to_logfile: yes
>>>    logfile: /my/new/location/corosync.log
>>
>>
>> By default, pacemaker will use the same log file as corosync, so this
>> should be sufficient.
>
>
> btw. this is something we have to fix. Basically what happens now (if I
> didn't overlooked something) is that pcmk is opening same file so it can be
> overwriting whatever corosync logs because corosync is using non-synced
> threaded logging.
>
> Honza
>
>
>>
>> Alternatively, you can explicitly tell Pacemaker what detail log file to
>> use with the environment variable PCMK_logfile (typically set in a
>> distro-specific location such as /etc/sysconfig/pacemaker or
>> /etc/default/pacemaker).
>>
>>>    # Log to the system log daemon. When in doubt, set to yes.
>>>    to_syslog: yes
>>>    # Log debug messages (very verbose). When in doubt, leave off.
>>>    debug: off
>>>    # Log messages with time stamps. When in doubt, set to on
>>>    # (unless you are only logging to syslog, where double
>>>    # timestamps can be annoying).
>>>    timestamp: on
>>>    logger_subsys {
>>>      subsys: QUORUM
>>>      debug: off
>>>    }
>>> }
>>> quorum {
>>>    provider: corosync_votequorum
>>>    expected_votes: 3
>>> }
>>>
>>> Thanks,
>>> Chris
>>
>>
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org
>> http://clusterlabs.org/mailman/listinfo/users
>>
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://bugs.clusterlabs.org
>>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org




More information about the Users mailing list