Michael -- Thanks for the response. I've found that while there is often a way to coax any given client to be happy with spacewalk, it often takes more manual intervention than I'd like.
I did a server upgrade to 1.8 yesterday and am taking the opportunity to visit each client to also upgrade the client repo to 1.8. I'm fiddling with a daily cron script on each client that does some steps (such as rhn-profile-sync and osad restart) that seems to be beneficial. I remain unable to find any set of actions, however, (either server-side or client-side) that can make my group of 65 (primarily CentOS 6) servers consistently happy. Andy On 2/25/13 4:02 AM, "Michael Mraka" <[email protected]> wrote: Andy Ingham wrote: % Thanks, Michael. I've looked at those logs as well and am noticing sql % connection errors such as: % % /var/log/rhn/osa-dispatcher.log:2013/02/19 09:14:12 -04:00 2452 0.0.0.0: % osad/jabber_lib.main('ERROR', 'Traceback (most recent call last):\n File % "/usr/share/rhn/osad/jabber_lib.py", line 117, in main\n % self.setup_config(config)\n File "/usr/share/rhn/osad/osa_dispatcher.py", % line 112, in setup_config\n rhnSQL.initDB()\n File % "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", % line 124, in initDB\n __init__DB(backend, host, port, username, % password, database)\n File % "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/__init__.py", % line 55, in __init__DB\n __DB.connect()\n File % "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql % .py", line 171, in connect\n return self.connect(reconnect=0)\n File % "/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql % .py", line 160, in connect\n password=self.password)\nSQLConnectError: % (None, None, \'spaceschema\', \'Attempting Re-Connect to the database % failed\')\n') Osa-dispatcher complaining about not been able to connect to database - it's most likely temporary database outage. On the other hand osa-dispatcher doesn't come into play when running yum update or rhn_check. So there should be a different (ISE related) error. % Thankfully, it *does* appear that completely deleting and re-registering % clients does the trick. I sure wish there was a quicker way to % consistently flush these errors across a large number of clients, though. % % Andy % % On 2/22/13 3:56 AM, "Michael Mraka" <[email protected]> wrote: % % Andy Ingham wrote: % % Hello list -- % % % % I've got a number of spacewalk clients that indicate in the GUI that they % % have critical updates needed, but the updates have been done (and yum on % % the client is happy). % % % % I've tried everything I can think of to clear this discrepancy to no % avail % % (rhn-profile-sync, restarts of osad and rhnsd, GUI-forced "package % % verify", spacewalk server restart, re-registration of the client). % ... % % <SNIP> % % 0, 'name': 'packages.verify'}) % % XMLRPC ProtocolError: <ProtocolError for [SERVER FQDN HERE] /XMLRPC: 500 % % Internal Server Error> % % Hi Andy, % % there should be more information about Internal Server Error in % /var/log/httpd/*error_log and/or /var/log/rhn/*.log. 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
