Description of problem:
Since 6.3, qdrouterd is configured to log to a dedicated file, per:
$ grep output /etc/qpid-dispatch/qdrouterd.conf
That causes qdrouterd does not further log via syslog by default.
Since the logfile isnt collected by foreman-debug, we lack qdrouterd logs in foreman-debug.
Two possible ways to fix this:
- collect the file (in /usr/share/foreman/script/foreman-debug.d/katello-debug.sh I guess)
- have in qdrouterd.conf:
(what would partially revert the change to separate logging, though)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. call foreman-debug and unpack the archive
2. search for qdrouterd.log there
2. no logfile collected
2. logfile to collect
Thanks Pavel, easy fix and backport as well.
The configuration with syslog is worth creating an upstream ticket, no BZ needed tho.
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/23556 has been resolved.
In Satellite 6.4, I'm not able to find the qdrouterd.log file
# cat /etc/qpid-dispatch/qdrouterd.conf
# tar -xf /var/tmp/foreman-debug-ykEFS.tar.xz
# find foreman-debug-ykEFS/ -name qdrouterd.log
# find /var -name qdrouterd.log
I just shutdown my Sat, can you verify this:
grep qrouterd.log /usr/share/foreman/script/foreman-debug.d/*
There was a change apparently which is adding:
It was merged here:
Maybe we missed cherry-pick?
Hi Lukas, there are still no results showing after running the command.
# grep qrouterd.log /usr/share/foreman/script/foreman-debug.d/*
Ok thanks, looks like it's katello version is 3.6.0
I am closing the bug unless there was some issue on the rel-eng side. Chris, can you confirm the bit landed in the snap correctly? I am currently unable to upgrade my snap due to other issue.
Sorry for the confusion, ignore comment 9.
Chris, I please retest with next snap.
I can confirm the logfile is not collected by Sat 6.3.2:
[root@pmoravec-sat63 ~]# rpm -q satellite katello
[root@pmoravec-sat63 ~]# grep -r qdrouterd $(rpm -ql katello-debug foreman-debug) | sort -u
/usr/share/foreman/script/foreman-debug.d/katello-debug.sh: add_files /etc/qpid-dispatch/qdrouterd.conf
and generated foreman-debug does contain only the config file.
So if the fix was added to RC1, then we / engineering should file BZ against RCM. Until that, the bug is still valid - foreman-debug shipped to customers still do not collect the logfile (and that is what matters to CEE).
Pavel, this is ON_QA for Satellite 6.4. I am not sure how rel-engs want to handle 6.3, it was not yet assigned into any errata. This is 6.4+6.3 BZ.
(In reply to Lukas Zapletal from comment #10)
> Sorry for the confusion, ignore comment 9.
> Chris, I please retest with next snap.
Hey Lukas, I'm still getting the same results using Satellite 6.4.0 snap 9.0
the file requested in BZ *is* being collected:
[root@next ~]# grep -n qdrouterd.log /usr/share/foreman/script/foreman-debug.d/katello-debug.sh
79: add_files /var/log/qdrouterd/qdrouterd.log
But it does not exist:
[root@next ~]# ls /var/log/qdrouterd/qdrouterd.log
ls: cannot access /var/log/qdrouterd/qdrouterd.log: No such file or directory
If you create a dummy contents debug/sosreport *will* collect it. Therefore IMHO this BZ is VERIFIED.
Why qrouterd is not configured for this file is another story, but this BZ is IMHO solved and closed.
[root@next ~]# grep output /etc/qpid-dispatch/qdrouterd.conf
Maybe pmoravec knows.
For the record, I was testing this with Satellite 6.4 and this seems to be correct - long term we want EVERYTHING to be in syslog. That is collected by debug script. For 6.4 this is IMHO VERIFIED.
I guess this needs to by cherrypicked into 6.3 and QAacked there tho.
On ony Sat or Caps 6.3 I tried, I see:
$ grep output /etc/qpid-dispatch/qdrouterd.conf
So the BZ is 6.3 related _only_, if 6.4 and onwards will log to syslog only.
(lzap, does it make sense to remove collecting the file from upstream foreman/katello-debug? as it seems to be ridiculous? I didnt know the recent change is about to be changed back :-S)
OK Thanks! I am not against but I won't do this :-)
We can move to VERIFIED and wait for 6.3 errata then.
(In reply to Lukas Zapletal from comment #15)
> the file requested in BZ *is* being collected:
> [root@next ~]# grep -n qdrouterd.log
> 79: add_files /var/log/qdrouterd/qdrouterd.log
> But it does not exist:
> [root@next ~]# ls /var/log/qdrouterd/qdrouterd.log
> ls: cannot access /var/log/qdrouterd/qdrouterd.log: No such file or directory
> If you create a dummy contents debug/sosreport *will* collect it. Therefore
> IMHO this BZ is VERIFIED.
> Why qrouterd is not configured for this file is another story, but this BZ
> is IMHO solved and closed.
> [root@next ~]# grep output /etc/qpid-dispatch/qdrouterd.conf
> output: syslog
> Maybe pmoravec knows.
Oh ok, thanks for the clarification.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.