Hi Yang

After creating several cloned repo’s I started to see 
“java.lang.OutOfMemoryError: Java heap space” messages in 
“/var/log/rhn/rhn_taskomatic_daemon.log” In addition, the generation of repo 
metadata, for some of the larger repo’s, wasn’t completing. There are lots of 
hits about this both in the lists and from Google! After increasing max memory 
for Java, from 512Mb to 4096Mb, I don’t seem to be having any more problems 
though☺ See this link for further background info:

            
https://docs.oracle.com/cd/E92593_01/E90695/html/swk24-issues-memory.html

Regards
Phil
From: spacewalk-list-boun...@redhat.com <spacewalk-list-boun...@redhat.com> On 
Behalf Of Yang Li
Sent: 16 January 2019 20:52
To: spacewalk-list@redhat.com
Subject: [Spacewalk-list] issue with new channel

I have new channel setup in our spacewalk server. the repo sync looks fine. on 
client side, it yum repolist looks fine, but when I do yum update, it will 
break out with following error:

# yum update  --nogpgcheck
Loaded plugins: rhnplugin
This system is receiving updates from RHN Classic or Red Hat Satellite.


One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

failed to retrieve repodata/repomd.xml from ius_rhel7_x86_64
error was [Errno 14] HTTPS Error 404 - Not Found

this is what I see in repo sync log:

# cat ius_rhel7_x86_64.log
2019/01/11 10:45:00 -04:00 Command: ['/usr/bin/spacewalk-repo-sync', 
'--channel', 'ius_rhel7_x86_64', '--type', 'yum']
2019/01/11 10:45:00 -04:00 Sync of channel started.
2019/01/11 10:45:00 -04:00 Repo URL: 
http://archive.linux.duke.edu/ius/stable/Redhat/7/x86_64/
2019/01/11 10:45:01 -04:00 Packages in repo:               737
2019/01/11 10:45:02 -04:00 Packages already synced:          0
2019/01/11 10:45:02 -04:00 Packages to sync:               737
2019/01/11 10:45:02 -04:00 1/737 : apcu-panel56u-4.0.11-2.ius.el7-0.noarch
2019/01/11 10:45:03 -04:00 2/737 : apr15u-1.5.2-2.ius.el7-0.x86_64
2019/01/11 10:45:05 -04:00 3/737 : apr15u-debuginfo-1.5.2-2.ius.el7-0.x86_64
...

2019/01/11 10:58:30 -04:00 731/737 : 
uwsgi-plugin-python35u-debuginfo-2.0.16-1.ius.el7-0.x86_64
2019/01/11 10:58:31 -04:00 732/737 : 
uwsgi-plugin-python35u-debuginfo-2.0.17.1-1.ius.el7-0.x86_64
2019/01/11 10:58:32 -04:00 733/737 : 
uwsgi-plugin-python36u-2.0.16-1.ius.el7-0.x86_64
2019/01/11 10:58:32 -04:00 734/737 : 
uwsgi-plugin-python36u-2.0.17.1-1.ius.el7-0.x86_64
2019/01/11 10:58:33 -04:00 735/737 : 
uwsgi-plugin-python36u-debuginfo-2.0.17.1-1.ius.el7-0.x86_64
2019/01/11 10:58:33 -04:00 736/737 : 
uwsgi-plugin-python36u-debuginfo-2.0.16-1.ius.el7-0.x86_64
2019/01/11 10:58:34 -04:00 737/737 : yum-plugin-replace-0.2.7-1.ius.el7-0.noarch
2019/01/11 10:58:35 -04:00 Linking packages to channel.
2019/01/11 10:58:42 -04:00 Repo 
http://archive.linux.duke.edu/ius/stable/Redhat/7/x86_64/ has 0 errata.
2019/01/11 10:58:42 -04:00 Sync of channel completed in 0:13:41.

What could be the issue?

Thanks,
Yang
_______________________________________________
Spacewalk-list mailing list
Spacewalk-list@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to