[Spacewalk-list] Server not creating/updating /var/cache/rhn after upgrade

Tue Feb 20 20:59:16 UTC 2018

Thanks!  I had been using the spacecmd softwarechannel_regenerateyumcache command and trying to use the bunch schedule in the web UI, but it wasn’t until a read your response that I realized these were two different things.  Apparently, I had to run the command in space cmd and THEN schedule the task bunch in the web UI to get it to actually do what I wanted.  It’s generating all of the repo lists now and I was able to verify with one of the clients that it can now see patches.  The web UI still shows no updates available for any given client, however I’m wondering if the task just needs to complete first before it will update that view.  

From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Brian Long
Sent: Tuesday, February 20, 2018 3:27 PM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Server not creating/updating /var/cache/rhn after upgrade

I've had similar issues on our SW server that has been upgraded over time.  Take a look here:
https://access.redhat.com/solutions/19303

cd /var/cache/rhn/repodata
rm -rf <one or more channel directories> (or mv <channel> /scratch to keep a backup)
/root/regen-repodata.py -a --url https://localhost/rpc/api

Login as admin with password

service taskomatic restart
Login to web UI using admin.  Click on Admin tab, Task Schedules.  Click the channel-repodata-bunch in the right column
Click on Single Run Schedule to start the job.
tail -50f /var/log/rhn/rhn_taskomatic_daemon.log to watch progress.

If the above tail from taskomatic does not output anything for a period over ten minutes but you've not seen metadata for every channel regenerated, follow steps 4-6 again.  The log will show the following but it should continue generating the metadata for the missing channels:

INFO   | jvm 1    | 2018/01/05 15:16:36 | 2018-01-05 15:16:36,189 [Thread-42] WARN  com.redhat.rhn.taskomatic.core.SchedulerKernel - Number of interrupted runs: 1

To verify metadata has been properly generated, login to a host and run the following commands:

yum clean metadata
yum repolist

For each repo, you should see a positive integer on the far right column.  If you see a 0, that means the metadata for that channel was not generated.

Even with all these steps, we ran into other issues and I'm in the process of rebuilding our SW server.

/Brian/

On Tue, Feb 20, 2018 at 2:34 PM, Glennie, Jonathan - 0443 - MITLL <jrglenni at ll.mit.edu <mailto:jrglenni at ll.mit.edu> > wrote:

Hi All-

I’m having an interesting issue where none of our software channels are creating any repomd.xml files.  There is a long history with this server, which may or may not be relevant to this problem, but it’s worth mentioning that this used to be a physical machine running 2.6 that we upgraded to 2.7.  After running in to various issue, we migrated the server to a VM running 2.7 using the procedure discussed here https://www.redhat.com/archives/spacewalk-list/2013-November/msg00070.html

I have tried manually restarting taskomatic and also using the spacecmd commands to regenerate the yum repodata, but nothing is being created in /var/cache/rhn.  The repodata directory is completely missing.  I checked the taskomatic logs and I don’t see any errors that would point to an issue, not sure where else to check.  

When running a yum list from a client, we get an error that the repomd.xml file (not surpsingly) couldn’t be found.  Out of curiosity, I tried manually copying over the old /var/cache/rhn/repodata directory over from the old server and after doing so, I can get past the repomd.xml error, but obviously this isn’t good if these repo files aren’t updating.  

_______________________________________________
Spacewalk-list mailing list
Spacewalk-list at redhat.com <mailto:Spacewalk-list at redhat.com> 
https://www.redhat.com/mailman/listinfo/spacewalk-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20180220/076a1b81/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5477 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20180220/076a1b81/attachment.p7s>