On 01/24/2017 04:41 PM, renayama19661...@ybb.ne.jp wrote: > Hi Ken, > > Thank you for comment. > > For example, our user does not use pacemaker.log and corosync.log. > > Via a syslog, the user makes setting to output all log to /var/log/ha-log. > > ----- > (/etc/corosycn/corosync.conf) > logging { > syslog_facility: local1 > debug: off > } > > (/etc/sysconfig/pacemaker) > PCMK_logfile=none > PCMK_logfacility=local1 > PCMK_logpriority=info > PCMK_fail_fast=yes > > (/etc/rsyslog.conf) > # Log anything (except mail) of level info or higher. > # Don't log private authentication messages! > *.info;mail.none;authpriv.none;cron.none;local1.none > /var/log/messages > (snip) > # Save boot messages also to boot.log > local7.* /var/log/boot.log > local1.info /var/log/ha-log > ----- > > In present crm_report, in the case of the user who output log in a different > file, the log is not collected in sosreport. > > Is this not a problem? > Possibly is all /var/log going to collect it in future in sosreport? > > Of course I know that "/var/log/ha-log" is collected definitely when I carry > out crm_report alone. > I want to know why collection of log of this crm_report was stopped in > sosreport. > > For REDHAT, will it be to be enough for collection of sosreport contents? > If it is such a thing, we can understand. > > - And.... I test crm_report at the present, but seem to have some problems. > - I intend to report the problem by Bugzilla again. > > Best Regards, > Hideo Yamauchi.
Hi Hideo, You are right, that is a problem. I've opened a Red Hat bug for sosreport: https://bugzilla.redhat.com/show_bug.cgi?id=1416535 > ----- Original Message ----- >> From: Ken Gaillot <kgail...@redhat.com> >> To: users@clusterlabs.org >> Cc: >> Date: 2017/1/24, Tue 08:15 >> Subject: Re: [ClusterLabs] [Question] About log collection of crm_report. >> >> On 01/23/2017 04:17 PM, renayama19661...@ybb.ne.jp wrote: >>> Hi All, >>> >>> When I carry out Pacemaker1.1.15 and Pacemaker1.1.16 in RHEL7.3, log in >> conjunction with pacemaker is not collected in the file which I collected in >> sosreport. >>> >>> >>> This seems to be caused by the next correction and pacemaker.py script of >> RHEL7.3. >>> >>> - >> https://github.com/ClusterLabs/pacemaker/commit/1bcad6a1eced1a3b6c314b05ac1d353adda260f6 >>> - >> https://github.com/ClusterLabs/pacemaker/commit/582e886dd8475f701746999c0093cd9735aca1ed#diff-284d516fab648676f5d93bc5ce8b0fbf >>> >>> >>> --- >>> (/usr/lib/python2.7/site-packages/sos/plugins/pacemaker.py) >>> (snip) >>> if not self.get_option("crm_scrub"): >>> crm_scrub = "" >>> self._log_warn("scrubbing of crm passwords has been >> disabled:") >>> self._log_warn("data collected by crm_report may >> contain" >>> " sensitive values.") >>> self.add_cmd_output('crm_report --sos-mode %s -S -d ' >>> ' --dest %s --from "%s"' % >>> (crm_scrub, crm_dest, crm_from), >>> chroot=self.tmp_in_sysroot()) >>> (snip) >>> --- >>> >>> >>> When a user carries out crm_report in sosreport, what is the reason that >> set search_logs to 0? >>> >>> We think that the one where search_logs works with 1 in sosreport is right. >>> >>> >>> Best Regards, >>> Hideo Yamauchi. >> >> Hi Hideo, >> >> The --sos-mode option is intended for RHEL integration, so it is only >> guaranteed to work with the combination of pacemaker and sosreport >> packages delivered with a particular version of RHEL (and its derivatives). >> >> That allows us to make assumptions about what sosreport features are >> available. It might be better to detect those features, but we haven't >> seen enough usage of sosreport + pacemaker outside RHEL to make that >> worth the effort. >> >> In this case, the version of sosreport that will be in RHEL 7.4 will >> collect pacemaker.log and corosync.log on its own, so the crm_report in >> pacemaker 1.1.16 doesn't need to collect the logs itself. >> >> It might work if you build the latest sosreport: >> https://github.com/sosreport/sos >> _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.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