Bug 603932 - JONServerDownloadActionHandler - zip file not copied to /tmp
JONServerDownloadActionHandler - zip file not copied to /tmp
Product: RHQ Project
Classification: Other
Component: Agent (Show other bugs)
All Linux
low Severity urgent (vote)
: ---
: ---
Assigned To: Charles Crouch
Mike Foley
Depends On:
Blocks: 603787
  Show dependency treegraph
Reported: 2010-06-14 18:24 EDT by Ondřej Žižka
Modified: 2015-02-01 18:26 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-07 09:57:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Agent log. (14.30 KB, text/plain)
2010-06-14 19:05 EDT, Ondřej Žižka
no flags Details

  None (edit)
Description Ondřej Žižka 2010-06-14 18:24:34 EDT
Description of problem:

When applying a patch to EAP, the zip file which should be downloaded by the agent from the JON server, does not end up in the expected location.

Agent log: 

2010-06-15 00:14:48,332 INFO  [ResourceContainer.invoker.nonDaemon-23] (jboss.on.common.jbossas.AbstractJBossASContentFacetDelegate)- Attempting to deploy package: PackageDetails[Key=PackageDetailsKey[Name=JBoss EAP 4.2.0.GA_CP09, Version=4.2.0.GA_CP09 Arch=noarch Type=cumulativePatch]]
2010-06-15 00:14:48,592 INFO  [ResourceContainer.invoker.nonDaemon-23] (jbossnetwork.product.jbpm.handlers.JONServerDownloadActionHandler)- Description of step [1]: Download file from the server and save it to [/tmp/jon_download2679847159410562741/JBEAP4.2.0_CP09/jboss-4.2.0.GA_CP09.zip].
2010-06-15 00:14:48,592 ERROR [ResourceContainer.invoker.nonDaemon-23] (jbossnetwork.product.jbpm.handlers.JONServerDownloadActionHandler)- Result of step [1]: message[null]

No messages in the server log.

The jon_download* dir in /tmp is created:

[ozizka@jawa18 jboss-web-cluster.sar]$ ls /tmp/jon_download2679847159410562741/ -la
total 16
drwxrwxr-x  2 ozizka ozizka 4096 Jun 15 00:14 .
drwxrwxrwt 21 root   root   4096 Jun 15 00:14 ..
[ozizka@jawa18 jboss-web-cluster.sar]$


1) Install JON 2.3.0 and JBoss AS/EAP plugins.
2) Install EAP 4.2.0 and let an agent monitor it.
3) tail -f rhq_agent/logs/rhq_agent.log
4) Register JBoss Patch source and install EAP 4.2.9 dist-diff patch.
5) Wait for the exception in agent's log.
Comment 2 Ondřej Žižka 2010-06-14 19:05:21 EDT
Created attachment 423993 [details]
Agent log.
Comment 3 Ondřej Žižka 2010-06-14 20:05:58 EDT
Agent's system:  RHEL 5 @ jawa18.englab.brq.redhat.com
running under a regular user
Comment 4 Ondřej Žižka 2010-06-30 17:39:02 EDT
Blocks EAP patches verification for CSP.
Comment 6 Charles Crouch 2010-06-30 17:49:33 EDT
I don't think this is a problem with copy files, more likely to be an issue with downloading the files in the first place.

One idea though, is /tmp on the same filesystem as where the agent is installed
Comment 7 Ondřej Žižka 2010-06-30 17:55:41 EDT
No, /tmp is on local HDD, work dir is on NFS.

Note that this worked in Boston lab, where the setup was similar, regarding this.
server @ dev35.qa.atl2.redhat.com.
agent  @ .qa.atl2.redhat.com (don't remember exactly)
Comment 8 Ondřej Žižka 2010-07-02 17:07:36 EDT
I tried with access.redhat.com as Charles suggested in #5.
Now it fails because the downloaded "zip" is actually a HTML page, seems like the root page.

23:01:47) ozizka`: it's a HTML file named ... zip
(23:02:13) ozizka`: So, either wrong metadata or server misbehaving
(23:02:19) ozizka`: other ideas?
(23:03:13) spinder: ozizka`: Or the CSP feed element is not being served up correctly.
(23:05:10) ozizka`: spinder: That's what I mean by metadata.
Comment 9 Ondřej Žižka 2010-07-02 17:54:20 EDT
For the record -

Digest of [/tmp/jon_download4495698412119601228/jboss-4.3.0.GA_CP01.zip]  is [50696e977bf2751e602f3c497c3521ca] and does not match expected value  [0c3284c13efc48eb5f43f755b23f0d5c]
Comment 11 Tom Mirc 2010-07-19 15:07:50 EDT
AMS has diagnosed issue:  

When referencing the URL provided in the stage environment, the browser is looking for a string on cookie "ChromeLocale" and failing on line 28 in the code when the call fails.  Upon further investigation, the cookie is not assigned in WebQA and Stage environments.  This is because, the cookie is an automated assignment from Redhat.com when a requestor attempts to access a URL with the pattern access.redhat.com.

In Stage, automated cookie assignment is not configured.  Therefore, all requests to the URL for "ChromeLocale" will fail, because the source of this data is not available.  

Possible resolutions at this point:

1) Remove the call for "ChromeLocale" from Stage and WebQA
2) Configure automatic cookie assignment in Stage and WebQA
3) Manufacture a cookie with the required data for internal users.

AMS is investigating which option is fastest to market.
Comment 12 Corey Welton 2010-09-24 09:18:51 EDT
cccrouch - what to do with this? needs to be reassigned to CSP?
Comment 13 Ondřej Žižka 2010-09-28 08:02:38 EDT
I think the problem at CSP side is solved.
Igor, what's the current state pls?
Comment 14 igilany 2010-09-29 05:59:01 EDT
Well it's mostly possible for JON to succesfully download the zip. But failures(0B zip files) are still occuring from time to time with stage csp, especially with bigger files(but every time it worked after re-trying).
Comment 16 Heiko W. Rupp 2013-09-25 09:02:21 EDT
Is that still an issue, as there have been a lot of changes and improvements since?
Comment 17 Heiko W. Rupp 2013-12-07 09:57:23 EST

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