Created attachment 586656 [details] Output of "rhn_check -vvv" Description of problem: I am new to Spacewalk so I will include as much detail as possible. I have a CentOS 6.2 server with Spacewalk 1.7 installed, Scientific Linux 6.2 clients are registered. The SL6 repos have been added and are synced with a cron job. Whenever I try to schedule a package installation it fails with the error: Client execution returned "Error while executing packages action: empty transaction [[6]]" (code -1) I have seen reports of this error and the advice was to use the nightly client. I have updated my client systems to the nightly client versions but the error still persists. Fair warning - I moved the "/var/satellite/redhat/1/" folder and sym-linked it back, I am hoping that this isn't what is causing these issues. I can't see how it could be as the location is still (from the FS perspective) the same. I only did this as there wasn't an option to specifify where the RPMs can be stored and I don't have enough room on /. If this is definitely the issue you can close this ticket. Version-Release number of selected component (if applicable): 1.7 on server and client, then the nightly client (yum-rhn-plugin-1.8.1-1.el6.noarch). How reproducible: Every time (for me). Steps to Reproduce: 1. Schedule a package update for a system, ASAP. 2. Run "rhn_check -vvv" on the system. 3. The packages don't install, logs are included. Actual results: The package(s) will not install. Expected results: The packages will install. Additional info: The output of "rhn_check -vvv" is attached.
I am sorry... I was able to fix this by restarting the taskomatic service on the Spacewalk server. For anyone coming in by Google: /etc/init.d/taskomatic restart And then: tail -f /var/log/rhn/rhn_taskomatic_daemon.log Until you see a message like the following in the logs: INFO | jvm 1 | 2012/05/24 16:15:09 | 2012-05-24 16:15:09,726 [Thread-55] INFO com.redhat.rhn.taskomatic.task.repomd.RepositoryWriter - Repository metadata generation for 'sl-62-x86_64' finished in 227 seconds I don't know if this a one-time issue, I see a reference in the mailing list archives to a similar issue that somebody fixed by restarting taskomatic. Perhaps I should just add the taskomatic restart to the repo sync script I have running in cron. Again, sorry for filing a bug report when I hadn't tried everything to get it working again.
OK, I'm closing this report based on comment #1.