Hide Forgot
Description of problem: When syncyng some repos, below red herring warning appears in /var/log/messages: Aug 30 09:39:31 satelliteserver pulp: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/MyOrg/Library/come-content-view/content/dist/rhel/server/7/7Server/x86_64/sat-tools/6.2/os/treeinfo Quoting mmccune: there is code that checks to see if a repo you are syncing has a kickstart tree. That is it just stating it didnt find one, which is in WARNING level. Since it is normal a repo does (not) have kickstart tree, that log shall be of DEBUG level rather. Version-Release number of selected component (if applicable): Sat 6.2 How reproducible: 100% Steps to Reproduce: 1. synchronize (some specific?) repo 2. check /var/log/messages Actual results: messages having above WARNING Expected results: messages not having that warning (just debug log when pulp debugs are enabled) Additional info: (not sure why I can't reproduce it on my Satellite - tried various repos to sync, never hit that WARN)
I am also not able to reproduce. I think this may have been fixed in some of the on-demand-sync work that was done, which changed retry behavior in the download workflow. Please NEEDSINFO me if you figure out how to reproduce it, but otherwise I suggest closing this.
(In reply to Michael Hrivnak from comment #3) > I am also not able to reproduce. I think this may have been fixed in some of > the on-demand-sync work that was done, which changed retry behavior in the > download workflow. > > Please NEEDSINFO me if you figure out how to reproduce it, but otherwise I > suggest closing this. OK closing it since dont have a reproducer either. Will reopen if I would found one.
Nov 08 12:07:31 satellite.mgmt.cloud.td.com pulp[25788]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/custom/TD_ODBC_Clients/tdodbc-clients/.treeinfo Nov 08 12:07:32 satellite.mgmt.cloud.td.com pulp[25790]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/custom/TD_ODBC_Clients/tdodbc-clients/treeinfo Nov 08 12:07:39 satellite.mgmt.cloud.td.com pulp[25790]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/custom/nexus/nexus/.treeinfo Nov 08 12:07:40 satellite.mgmt.cloud.td.com pulp[25788]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/custom/nexus/nexus/treeinfo Nov 08 12:07:44 satellite.mgmt.cloud.td.com pulp[25790]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/content/dist/rhel/server/6/6Server/x86_64/sat-tools/6.2/os/.treeinfo Nov 08 12:07:45 satellite.mgmt.cloud.td.com pulp[25790]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/content/dist/rhel/server/6/6Server/x86_64/sat-tools/6.2/os/treeinfo Nov 08 12:07:46 satellite.mgmt.cloud.td.com pulp[25788]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/Compute/Library/content/dist/rhel/server/7/7.2/x86_64/kickstart/.treeinfo Nov 08 12:07:52 satellite.mgmt.cloud.td.com pulp[25790]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/content/dist/rhel/server/6/6Server/x86_64/loadbalancer/os/.treeinfo Nov 08 12:07:53 satellite.mgmt.cloud.td.com pulp[25789]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/content/dist/rhel/server/6/6Server/x86_64/loadbalancer/os/treeinfo Nov 08 12:08:00 satellite.mgmt.cloud.td.com pulp[25789]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/TD_Cloud/Library/content/dist/rhel/server/7/7Server/x86_64/sat-tools/6.2/os/.treeinfo
Reopening the ticket as it is reported recently(linked with the consumer portal's case number)
On further examination, this particular log message appears to happen when a client requests a file from pulp that does not exist in a published repo, and gets a 404. I reproduced with the following steps: - sync and publish the repo found here: https://repos.fedorapeople.org/repos/pulp/pulp/fixtures/rpm/ - curl -k https://localhost/pulp/repos/repos/pulp/pulp/fixtures/rpm/helloworld This resulted in the following message in the system log: Jan 03 20:20:31 dev pulp[3152]: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/repos/pulp/pulp/fixtures/rpm/helloworld So I believe the ".treeinfo" message is seen when a yum client attempts to retrieve that file, which legitimately and rightfully does not exist. We should try to prevent django from logging a warning in this case.
The Pulp upstream bug status is at POST. Updating the external tracker on this bug.
The Pulp upstream bug priority is at Normal. Updating the external tracker on this bug.
The Pulp upstream bug status is at MODIFIED. Updating the external tracker on this bug.
All upstream Pulp bugs are at MODIFIED+. Moving this bug to POST.
The Pulp upstream bug status is at ON_QA. Updating the external tracker on this bug.
The Pulp upstream bug status is at CLOSED - CURRENTRELEASE. Updating the external tracker on this bug.
(In reply to Michael Hrivnak from comment #8) > On further examination, this particular log message appears to happen when a > client requests a file from pulp that does not exist in a published repo, > and gets a 404. > > I reproduced with the following steps: > > - sync and publish the repo found here: > https://repos.fedorapeople.org/repos/pulp/pulp/fixtures/rpm/ > - curl -k > https://localhost/pulp/repos/repos/pulp/pulp/fixtures/rpm/helloworld > > This resulted in the following message in the system log: > > Jan 03 20:20:31 dev pulp[3152]: django.request:WARNING: Not Found: > /var/www/pub/yum/https/repos/repos/pulp/pulp/fixtures/rpm/helloworld > > So I believe the ".treeinfo" message is seen when a yum client attempts to > retrieve that file, which legitimately and rightfully does not exist. We > should try to prevent django from logging a warning in this case. Today we noticed similar string there: Jan 24 15:15:08 satellite pulp: django.request:WARNING: Not Found: /var/www/pub/yum/https/repos/Organization_SI/RHEL5_DMZ_SOMETHING_PROD/RHEL5/content/dist/rhel/server/5/5Server/x86_64/os/repodata/repomd.xml doe it belong to the fix as well? The repomd.xml in metadata is something new.. (no known reproducer, though)
Pavel, either you don't have the fix, or it isn't working as expected. With the fix, "django.request" should never log anything at WARNING. To clarify reproduction: All you need to do is request a file from Pulp that doesn't exist. In this case, someone must have requested: /pulp/repos/Organization_SI/RHEL5_DMZ_SOMETHING_PROD/RHEL5/content/dist/rhel/server/5/5Server/x86_64/os/repodata/repomd.xml and apparently that file didn't exist.
(In reply to Michael Hrivnak from comment #16) > Pavel, either you don't have the fix, or it isn't working as expected. With > the fix, "django.request" should never log anything at WARNING. > > To clarify reproduction: All you need to do is request a file from Pulp that > doesn't exist. In this case, someone must have requested: > > /pulp/repos/Organization_SI/RHEL5_DMZ_SOMETHING_PROD/RHEL5/content/dist/rhel/ > server/5/5Server/x86_64/os/repodata/repomd.xml > > and apparently that file didn't exist. Yes, the fix isnt applied on that Satellite. So I understood that some client requested that URI that does not exist on the pulp server. It makes sense to raise some warning (it is sort of 404 error), but I expect they will be logged as the 404 errors in httpd access ssl logs either way. So ok if django.request won't log anything under WARNING.
Verification version: Satellite 6.3 Snap 13 Verification steps: 1. sychrnized repository 2. tail -f /var/log/messages 3. curl -k http://cisco-b200m1-04.rhts.eng.bos.redhat.com/pulp/repos/Default_Organization/Library/content/dist/rhel/server/7/7.4/x86_64/kickstart/missing-file No error messages produced in /var/log/messages, the curl returns 404, as expected
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. https://access.redhat.com/errata/RHSA-2018:0336