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 <[email protected]> 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: [email protected] >> 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: [email protected] > 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: [email protected] 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
