Bug 1043909

Summary: Cleanup deploy directories after kill
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Shaun Appleton <sappleto>
Component: OtherAssignee: Jason Greene <jason.greene>
Status: CLOSED DUPLICATE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: brian.stansberry, lakagwu
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://c.na7.visual.force.com/apex/Case_View?id=500A000000Beywm
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-04-30 18:26:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Shaun Appleton 2013-12-17 12:41:48 UTC
Raising this as other bz was closed

Description of problem:
https://bugzilla.redhat.com/show_bug.cgi?id=901210 fixed an issue with Cleanup deploy directories but this does not work when the instance is killed and restarted

Steps to Reproduce:
Testing using EAP6.2.beta1 shows a circumstance where the folder can grow:

1) start server -> creates tmp folder and add content
2) kill server -> remaining content in tmp, is accepted as it is a kill
3) start server
4) shutdown server using CLI

What is seen is that:
- a shutdown brings back the tmp folder size to the size before the corresponding start, so it's not growing, but
- the trash from a kill is never removed, so a crash or kill increases the folder size.

RH Consultant on-site at LODH confirms using EAP6.2.GA:

These are the sizes of the tmp-folder:
4'771'836 running
4'771'836 after kill
7'157'754 after restart
4'771'836 after shutdown
7'157'754 after restart
7'157'754 after kill
9'543'672 after restart
7'157'754 after shutdown

So the folder is still not cleaned-up as expected.

Comment 3 Brian Stansberry 2014-04-30 18:26:36 UTC
Closing as a duplicate since 901210 was reopened for 6.3.

*** This bug has been marked as a duplicate of bug 901210 ***