[Spacewalk-list] Oracle Linux 6 repo not fully synched?

Coffman, Anthony J Tony.Coffman at snapon.com
Mon Mar 18 15:22:05 UTC 2013 

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: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Coffman, Anthony J
Sent: Monday, March 18, 2013 9:35 AM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Oracle Linux 6 repo not fully synched?

Thanks.  That explains this perfectly.

Regards,
--Tony


-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Michael Mraka
Sent: Monday, March 18, 2013 3:39 AM
To: spacewalk-list at redhat.com
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
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list

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

More information about the Spacewalk-list mailing list