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. ----- 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 > _______________________________________________ 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