I've solved the problem. I've found this exception on the log rhn_taskomatic_daemon.log: INFO | jvm 1 | 2015/10/09 12:31:55 | Exception in thread "Thread-53" java.lang.OutOfMemoryError: GC overhead limit exceeded INFO | jvm 1 | 2015/10/09 12:31:55 | at java.lang.reflect.Method.copy(Method.java:162) INFO | jvm 1 | 2015/10/09 12:31:55 | at java.lang.reflect.ReflectAccess.copyMethod(ReflectAccess.java:136) INFO | jvm 1 | 2015/10/09 12:31:55 | at sun.reflect.ReflectionFactory.copyMethod(ReflectionFactory.java:300) INFO | jvm 1 | 2015/10/09 12:31:55 | at java.lang.Class.copyMethods(Class.java:2894) INFO | jvm 1 | 2015/10/09 12:31:55 | at java.lang.Class.getMethods(Class.java:1469) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.addToObject(CachedStatement.java:739) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.processResultSet(CachedStatement.java:626) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:474) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:443) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:345) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:351) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:287) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.common.db.datasource.SelectMode.execute(SelectMode.java:110) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.manager.task.TaskManager.getChannelPackageDtos(TaskManager.java:52) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.taskomatic.task.repomd.RpmRepositoryWriter.writeRepomdFiles(RpmRepositoryWriter.java:179) INFO | jvm 1 | 2015/10/09 12:31:55 | at com.redhat.rhn.taskomatic.task.repomd.ChannelRepodataWorker.run(ChannelRepodataWorker.java:104) INFO | jvm 1 | 2015/10/09 12:31:55 | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761) INFO | jvm 1 | 2015/10/09 12:31:55 | at java.lang.Thread.run(Thread.java:701)
So I've changed the max memory used from taskomatic from 2 to 3 Gb, here, /usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf: wrapper.java.maxmemory=3072 Then repodata of my channel has rebuiled correctly, so now my subscribed client are updating again ;) >From system history events: This action will be executed after 10/9/15 2:48:00 PM CEST This action's status is: Completed. The client picked up this action on 10/9/15 8:48 AM The client completed this action on 10/9/15 8:48 AM Client execution returned "Update Succeeded" (code 0) Bye bye, Morgan 2015-10-09 11:12 GMT+02:00 Morgan Marodin <[email protected]>: > Hi everyone. > > I've a problem with my spacewalk 2.2 installation. > > Spacewalk console is showing me that my system has 2 ERRATA to apply, but > if I try to apply Errata, or packages, from the console it fails. > If I try to execute yum update directly from the clients, they don't show > any update: > # yum update > Loaded plugins: rhnplugin, ulninfo > This system is receiving updates from RHN Classic or Red Hat Satellite. > Setting up Update Process > No Packages marked for Update > > I've tried to rename the repo folder under /var/cache/rhn/repodata/ path > and then restart the service, and execute yum clean all ; yum list from a > subscribed client, but spacewalk does not regenerarte the repo, I've waited > for 1 day long ... for nothing. > So I have renamed the old repo folder with the correct name, restart the > service, and remove problem packages from spacewalk console. Then I have > launched the sync of the channel and spacewalk has downloaded again these > rpms, but the problem persist! > > From system history events: > This action will be executed after 10/9/15 11:04:00 AM CEST > This action's status is: Failed. > The client picked up this action on 10/9/15 5:04 AM > The client completed this action on 10/9/15 5:04 AM > Client execution returned "Failed: Packages failed to install properly: > Package tzdata-0:2015g-2.el6.noarch is not available for installation > Package tzdata-java-0:2015g-2.el6.noarch is not available for installation" > (code 32) > > From client's logs: > [Fri Oct 9 11:04:03 2015] up2date updateLoginInfo() login info > [Fri Oct 9 11:04:03 2015] up2date logging into up2date server > [Fri Oct 9 11:04:03 2015] up2date successfully retrieved authentication > token from up2date server > [Fri Oct 9 11:04:03 2015] up2date E: Package tzdata-0:2015g-2.el6.noarch > is not available for installation > [Fri Oct 9 11:04:03 2015] up2date E: Package > tzdata-java-0:2015g-2.el6.noarch is not available for installation > [Fri Oct 9 11:04:03 2015] up2date updateLoginInfo() login info > [Fri Oct 9 11:04:03 2015] up2date logging into up2date server > [Fri Oct 9 11:04:04 2015] up2date successfully retrieved authentication > token from up2date server > [Fri Oct 9 11:04:04 2015] up2date E: Package > openldap-0:2.4.40-6.el6_7.x86_64 is not available for installation > [Fri Oct 9 11:04:04 2015] up2date E: Package > openldap-devel-0:2.4.40-6.el6_7.x86_64 is not available for installation > > There is a right way to rebuild the repo data of that channel? > > > Please let me know. > Thanks, bye. > Morgan >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
