Bug 824906 - Client execution returned "Error while executing packages action: empty transaction [[6]]" (code -1)
Client execution returned "Error while executing packages action: empty trans...
Status: CLOSED NOTABUG
Product: Spacewalk
Classification: Community
Component: Clients (Show other bugs)
1.7
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Milan Zazrivec
Red Hat Satellite QA List
:
Depends On:
Blocks: space18
  Show dependency treegraph
 
Reported: 2012-05-24 10:55 EDT by Dan Bryant
Modified: 2012-11-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-25 02:52:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of "rhn_check -vvv" (4.71 KB, text/plain)
2012-05-24 10:55 EDT, Dan Bryant
no flags Details

  None (edit)
Description Dan Bryant 2012-05-24 10:55:37 EDT
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.
Comment 1 Dan Bryant 2012-05-24 11:48:04 EDT
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.
Comment 2 Milan Zazrivec 2012-05-25 02:52:19 EDT
OK, I'm closing this report based on comment #1.

Note You need to log in before you can comment on or make changes to this bug.