So now I'm confident my Oracle channel is fully in synch with the web repo but I think I have another problem.
It appears that the yum metadata for the Oracle 6 Latest channel isn't building correctly due to a JVM garbage collection issue. I noticed this when trying to patch some Oracle boxes - they weren't apply any patches and yum repolist was showing zero packages in the ol6_latest channel. Taskomatic is throwing garbage collection exceptions even right after a Taskomatic/Spacewalk restart. This has been discussed before last year. https://www.redhat.com/archives/spacewalk-list/2012-July/msg00111.html Last month during our sync we were able to get it built by restarting Taskomatic a couple of times but this month it's consistently failing no matter how many times I run it. The clients see zero packages in the repository. It appears that we can tweak the JVM in /usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf to work around this issue., It looks like we can increase max heap or turn off the GC warning. I turned up the Java heap max from 1024M to 1536M and it seems to be working reliably now. Are there any recommendation on the best JVM tweak to make (or other workaround)? I'm not particularly concerned about memory in my install so much as I am about making it run reliably. It would help if Oracle knew how to run an organized repo but instead they just throw everything into this channel and I've got to deal with it. Thanks, --Tony INFO | jvm 1 | 2013/03/18 10:23:03 | 2013-03-18 10:23:03,718 [Thread-54] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Generating new repository metadata for channel 'ol6_latest'(sha1) 16545 packages, 1151 errata INFO | jvm 1 | 2013/03/18 10:25:03 | Exception in thread "Thread-54" java.lang.OutOfMemoryError: GC overhead limit exceeded INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.util.PGbytea.toBytes(PGbytea.java:91) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBytes(AbstractJdbc2ResultSet.java:2271) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(AbstractJdbc2ResultSet.java:150) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(AbstractJdbc3ResultSet.java:38) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(AbstractJdbc4ResultSet.java:298) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2541) INFO | jvm 1 | 2013/03/18 10:25:03 | at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2550) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.mchange.v2.c3p0.impl.NewProxyResultSet.getObject(NewProxyResultSet.java:73) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.getObject(CachedStatement.java:782) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.addToObject(CachedStatement.java:765) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.processResultSet(CachedStatement.java:615) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:469) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:438) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:340) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:346) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.CachedStatement.execute(CachedStatement.java:282) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.common.db.datasource.SelectMode.execute(SelectMode.java:110) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.manager.task.TaskManager.getChannelPackageDtos(TaskManager.java:52) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.taskomatic.task.repomd.RpmRepositoryWriter.writeRepomdFiles(RpmRepositoryWriter.java:170) INFO | jvm 1 | 2013/03/18 10:25:03 | at com.redhat.rhn.taskomatic.task.repomd.ChannelRepodataWorker.run(ChannelRepodataWorker.java:104) INFO | jvm 1 | 2013/03/18 10:25:03 | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:761) INFO | jvm 1 | 2013/03/18 10:25:03 | at java.lang.Thread.run(Thread.java:679) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Coffman, Anthony J Sent: Monday, March 18, 2013 9:35 AM To: [email protected] Subject: Re: [Spacewalk-list] Oracle Linux 6 repo not fully synched? Thanks. That explains this perfectly. Regards, --Tony -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Mraka Sent: Monday, March 18, 2013 3:39 AM To: [email protected] Subject: Re: [Spacewalk-list] Oracle Linux 6 repo not fully synched? Coffman, Anthony J wrote: % I'm starting to sync Oracle Linux for the first time and I noticed this happening % % Sync started: Wed Mar 13 16:05:44 2013 % ['/usr/bin/spacewalk-repo-sync', '--channel', 'ol6_latest', '--type', 'yum'] % Repo URL: http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/ % Packages in repo: 20868 % Packages already synced: 0 % Packages to sync: 16519 % 1/16519 : tk-devel-8.5.7-5.el6-1.x86_64 % 2/16519 : tk-devel-8.5.7-5.el6-1.i686 % 3/16519 : totem-upnp-2.28.6-2.el6-0.x86_64 % % <SNIP 16000+ packages syncing) % % 16518/16519 : kernel-devel-2.6.32-358.2.1.el6-0.x86_64 % 16519/16519 : kernel-doc-2.6.32-358.2.1.el6-0.noarch % Linking packages to channel. % Repo http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/ has comps file comps.xml. % Repo http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/ has 1148 errata. % Sync completed. % Total time: 9:39:22 % % I don't understand the discrepancy between the 20868 packages that are available in the Oracle repo but only 16519 are selected to sync. % % I found that Daniel Schindler had also mentioned this in a tangentially related bugzilla from a few months ago % https://bugzilla.redhat.com/show_bug.cgi?id=860860 % % I'm digging through the source now to try to understand this but I haven't found any obvious filtering going on. % % Cany anbody shed some light on this? IMHO it's 4349 src.rpm packages which spacewalk doesn't sync. % Regards, % --Tony Regards, -- Michael Mráka Satellite Engineering, Red Hat _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
