Quantcast

exception during shell.exec() calls

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

exception during shell.exec() calls

sodul
Hi,

While deploying some server tonight, all the applications failed to install at first and the console log showed several "java.io.IOException: Stream closed" exceptions.

def py_cmd = "${py_layer_script} --project ${project} --component ${product} --action install --build ${build}"
shell.exec("${py_cmd} 2>&1")

By the time we reach this shell exec there has been a few other calls with success. There are only 12s elapsed between the shell.exec() and the exception. Could it be because of the waitForState timeout ? We had some steps that can take several minutes to run and it has not been an issue before.

It started working again eventually but I'm wondering why this would have happened:

2012/10/04 19:34:13.224 INFO [/ed/fooserver] clearError
2012/10/04 19:34:13.390 INFO [/ed/fooserver] executeAction([action:unconfigure, mountPoint:/ed/fooserver, actionArgs:[:]]): 8f33e646-07d1-4d91-95e3-fb015f45dea8
2012/10/04 19:34:13.795 INFO [/ed/fooserver] Stopping fooserver ed-fooserver-prod-mdebug-s10143-j22
2012/10/04 19:34:14.004 INFO [/ed/fooserver] /mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action unconfigure
2012/10/04 19:34:14.250 INFO [/ed/fooserver] Unconfiguration complete.
2012/10/04 19:34:14.325 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): true
2012/10/04 19:34:14.511 INFO [/ed/fooserver] clearError
2012/10/04 19:34:14.676 INFO [/ed/fooserver] executeAction([action:uninstall, mountPoint:/ed/fooserver, actionArgs:[:]]): 9a5601e5-629f-4694-9f07-e4d5c69046a7
2012/10/04 19:34:14.802 INFO [/ed/fooserver] Uninstall.
2012/10/04 19:34:14.964 INFO [/ed/fooserver] waitForState([state:NONE, timeout:10s, mountPoint:/ed/fooserver]): true
2012/10/04 19:34:15.149 INFO [/ed/fooserver] clearError
2012/10/04 19:34:15.257 INFO [/ed/fooserver] uninstalled
2012/10/04 19:34:15.983 INFO [/ed/fooserver] installScript([initParameters:[master_ip:192.168.0.147, pygluLocation:https://ec2-bootstrap/glu/glu.py, metadata:[product:fooserver, ig_project:ed, host:[role:sessionrouter, short_name:fooserver003, zone:us-west-2a]], version:ed-fooserver-prod-mdebug-s10875-j26], mountPoint:/ed/fooserver, scriptLocation:https://ec2-bootstrap/glu/IgGluScript.groovy])
2012/10/04 19:34:16.251 INFO [/ed/fooserver] clearError
2012/10/04 19:34:16.551 INFO [/ed/fooserver] executeAction([action:install, mountPoint:/ed/fooserver, actionArgs:[:]]): 2f0b6ecc-a430-4310-bf14-3c3564b108ca
2012/10/04 19:34:18.203 INFO [/ed/fooserver] Installing fooserver ed-fooserver-prod-mdebug-s10875-j26 to /mnt/ig/ed/fooserver
2012/10/04 19:34:18.204 INFO [/ed/fooserver] params: [master_ip:192.168.0.147, pygluLocation:https://ec2-bootstrap/glu/glu.py, metadata:[product:fooserver, ig_project:ed, host:[role:sessionrouter, short_name:fooserver003, zone:us-west-2a]], version:ed-fooserver-prod-mdebug-s10875-j26]
2012/10/04 19:34:18.306 INFO [/ed/fooserver] Installing https://ec2-bootstrap/glu/glu.py to /mnt/ig/ed/fooserver/glu.py
2012/10/04 19:34:18.384 INFO [/ed/fooserver] /mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action install --build ed-fooserver-prod-mdebug-s10875-j26
2012/10/04 19:34:26.617 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): false
2012/10/04 19:34:36.683 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): false
2012/10/04 19:34:36.808 INFO [/ed/fooserver] interruptAction([action:install, mountPoint:/ed/fooserver])
Exception in thread "/mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action install --build ed-fooserver-prod-mdebug-s10875-j26 2>&1" org.codehaus.groovy.runtime.InvokerInvocationException: java.io.IOException: Stream closed
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
        at groovy.lang.Closure.call(Closure.java:276)
        at groovy.lang.Closure.call(Closure.java:271)
        at groovy.lang.Closure.run(Closure.java:354)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Stream closed
        at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:255)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.leftShift(DefaultGroovyMethods.java:6962)
        at org.codehaus.groovy.runtime.dgm$363.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:270)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
        at org.linkedin.glu.agent.impl.capabilities.ShellImpl$_forkAndExec2_closure20.doCall(ShellImpl.groovy:867)
        at sun.reflect.GeneratedMethodAccessor1014.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
        at org.linkedin.glu.agent.impl.capabilities.ShellImpl$_forkAndExec2_closure20.doCall(ShellImpl.groovy)
        at sun.reflect.GeneratedMethodAccessor1013.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
        ... 7 more
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

frenchyan
Administrator
The following lines in your stack trace:

2012/10/04 19:34:36.683 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): false 
2012/10/04 19:34:36.808 INFO [/ed/fooserver] interruptAction([action:install, mountPoint:/ed/fooserver]) 

seem to indicate that waitForState was actually working (otherwise the agent would not print this out…)

The next line seems to show that the action got intererruped. You can check in the audit log to see if somebody did issue an interrupt. Otherwise it is a little weird. I am in the process of reworking the shell.exec layer entirely. I wonder if there is a bug in the current one.

Yan

On Thu, Oct 4, 2012 at 5:56 PM, sodul [via glu] <[hidden email]> wrote:
Hi,

While deploying some server tonight, all the applications failed to install at first and the console log showed several "java.io.IOException: Stream closed" exceptions.

def py_cmd = "${py_layer_script} --project ${project} --component ${product} --action install --build ${build}"
shell.exec("${py_cmd} 2>&1")

By the time we reach this shell exec there has been a few other calls with success. There are only 12s elapsed between the shell.exec() and the exception. Could it be because of the waitForState timeout ? We had some steps that can take several minutes to run and it has not been an issue before.

It started working again eventually but I'm wondering why this would have happened:

2012/10/04 19:34:13.224 INFO [/ed/fooserver] clearError
2012/10/04 19:34:13.390 INFO [/ed/fooserver] executeAction([action:unconfigure, mountPoint:/ed/fooserver, actionArgs:[:]]): 8f33e646-07d1-4d91-95e3-fb015f45dea8
2012/10/04 19:34:13.795 INFO [/ed/fooserver] Stopping fooserver ed-fooserver-prod-mdebug-s10143-j22
2012/10/04 19:34:14.004 INFO [/ed/fooserver] /mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action unconfigure
2012/10/04 19:34:14.250 INFO [/ed/fooserver] Unconfiguration complete.
2012/10/04 19:34:14.325 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): true
2012/10/04 19:34:14.511 INFO [/ed/fooserver] clearError
2012/10/04 19:34:14.676 INFO [/ed/fooserver] executeAction([action:uninstall, mountPoint:/ed/fooserver, actionArgs:[:]]): 9a5601e5-629f-4694-9f07-e4d5c69046a7
2012/10/04 19:34:14.802 INFO [/ed/fooserver] Uninstall.
2012/10/04 19:34:14.964 INFO [/ed/fooserver] waitForState([state:NONE, timeout:10s, mountPoint:/ed/fooserver]): true
2012/10/04 19:34:15.149 INFO [/ed/fooserver] clearError
2012/10/04 19:34:15.257 INFO [/ed/fooserver] uninstalled
2012/10/04 19:34:15.983 INFO [/ed/fooserver] installScript([initParameters:[master_ip:192.168.0.147, pygluLocation:https://ec2-bootstrap/glu/glu.py, metadata:[product:fooserver, ig_project:ed, host:[role:sessionrouter, short_name:fooserver003, zone:us-west-2a]], version:ed-fooserver-prod-mdebug-s10875-j26], mountPoint:/ed/fooserver, scriptLocation:https://ec2-bootstrap/glu/IgGluScript.groovy])
2012/10/04 19:34:16.251 INFO [/ed/fooserver] clearError
2012/10/04 19:34:16.551 INFO [/ed/fooserver] executeAction([action:install, mountPoint:/ed/fooserver, actionArgs:[:]]): 2f0b6ecc-a430-4310-bf14-3c3564b108ca
2012/10/04 19:34:18.203 INFO [/ed/fooserver] Installing fooserver ed-fooserver-prod-mdebug-s10875-j26 to /mnt/ig/ed/fooserver
2012/10/04 19:34:18.204 INFO [/ed/fooserver] params: [master_ip:192.168.0.147, pygluLocation:https://ec2-bootstrap/glu/glu.py, metadata:[product:fooserver, ig_project:ed, host:[role:sessionrouter, short_name:fooserver003, zone:us-west-2a]], version:ed-fooserver-prod-mdebug-s10875-j26]
2012/10/04 19:34:18.306 INFO [/ed/fooserver] Installing https://ec2-bootstrap/glu/glu.py to /mnt/ig/ed/fooserver/glu.py
2012/10/04 19:34:18.384 INFO [/ed/fooserver] /mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action install --build ed-fooserver-prod-mdebug-s10875-j26
2012/10/04 19:34:26.617 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): false
2012/10/04 19:34:36.683 INFO [/ed/fooserver] waitForState([state:installed, timeout:10s, mountPoint:/ed/fooserver]): false
2012/10/04 19:34:36.808 INFO [/ed/fooserver] interruptAction([action:install, mountPoint:/ed/fooserver])
Exception in thread "/mnt/ig/ed/fooserver/glu.py --project ed --component fooserver --action install --build ed-fooserver-prod-mdebug-s10875-j26 2>&1" org.codehaus.groovy.runtime.InvokerInvocationException: java.io.IOException: Stream closed
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:95)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
        at groovy.lang.Closure.call(Closure.java:276)
        at groovy.lang.Closure.call(Closure.java:271)
        at groovy.lang.Closure.run(Closure.java:354)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Stream closed
        at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:255)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
        at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
        at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
        at org.codehaus.groovy.runtime.DefaultGroovyMethods.leftShift(DefaultGroovyMethods.java:6962)
        at org.codehaus.groovy.runtime.dgm$363.invoke(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:270)
        at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
        at org.linkedin.glu.agent.impl.capabilities.ShellImpl$_forkAndExec2_closure20.doCall(ShellImpl.groovy:867)
        at sun.reflect.GeneratedMethodAccessor1014.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
        at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:273)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
        at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
        at org.linkedin.glu.agent.impl.capabilities.ShellImpl$_forkAndExec2_closure20.doCall(ShellImpl.groovy)
        at sun.reflect.GeneratedMethodAccessor1013.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
        ... 7 more



If you reply to this email, your message will be added to the discussion below:
http://glu.977617.n3.nabble.com/exception-during-shell-exec-calls-tp4025035.html
To start a new topic under glu, email [hidden email]
To unsubscribe from glu, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

sodul
In reply to this post by sodul
I found the following in the archived deployment logs:
    <sequential agent="i-15763426" mountPoint="/ed/fooserver" startTime="2012-10-04 19:34:11 -0700" endTime="2012-10-04 19:34:31 -0700" status="PARTIAL">
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Run [unconfigure] phase for [/ed/fooserver] on [i-15763426]" scriptAction="unconfigure" toState="installed" startTime="2012-10-04 19:34:11 -0700" endTime="2012-10-04 19:34:13 -0700" status="COMPLETED" />
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Run [uninstall] phase for [/ed/fooserver] on [i-15763426]" scriptAction="uninstall" toState="NONE" startTime="2012-10-04 19:34:13 -0700" endTime="2012-10-04 19:34:13 -0700" status="COMPLETED" />
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Uninstall script for [/ed/fooserver] on [i-15763426]" scriptLifecycle="uninstallScript" startTime="2012-10-04 19:34:13 -0700" endTime="2012-10-04 19:34:14 -0700" status="COMPLETED" />
      <leaf agent="i-15763426" fabric="live" initParameters="{master_ip=172.30.10.147, metadata={host={role=fooserver, short_name=fooserver003, zone=us-west-2a}, ig_project=ed, product=fooserver}, pygluLocation=https://ec2-bootstrap/glu/glu.py, version=ed-fooserver-prod-mdebug-s10875-j26}" mountPoint="/ed/fooserver" name="Install script for [/ed/fooserver] on [i-15763426]" script="https://ec2-bootstrap/glu/IgGluScript.groovy" scriptLifecycle="installScript" startTime="2012-10-04 19:34:14 -0700" endTime="2012-10-04 19:34:14 -0700" status="COMPLETED" />
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Run [install] phase for [/ed/fooserver] on [i-15763426]" scriptAction="install" toState="installed" startTime="2012-10-04 19:34:14 -0700" endTime="2012-10-04 19:34:31 -0700" status="CANCELLED" />
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Run [configure] phase for [/ed/fooserver] on [i-15763426]" scriptAction="configure" toState="stopped" startTime="2012-10-04 19:34:31 -0700" endTime="2012-10-04 19:34:31 -0700" status="SKIPPED" />
      <leaf agent="i-15763426" fabric="live" mountPoint="/ed/fooserver" name="Run [start] phase for [/ed/fooserver] on [i-15763426]" scriptAction="start" toState="running" startTime="2012-10-04 19:34:31 -0700" endTime="2012-10-04 19:34:31 -0700" status="SKIPPED" />
    </sequential>

But then I noticed, in the same log that on an other machine things did not deploy properly:
<leaf agent="i-13763420" fabric="live" mountPoint="/ed/barserver" name="Run [stop] phase for [/ed/barserver] on [i-13763420]" scriptAction="stop" toState="stopped" startTime="2012-10-04 19:34:11 -0700" endTime="2012-10-04 19:34:12 -0700" status="FAILED">
        <exception message="java.lang.IllegalStateException: no valid transition found for 'stop' from [currentState:stopped]: valid action(s) [start, unconfigure]">org.linkedin.glu.agent.api.ScriptIllegalStateException: java.lang.IllegalStateException: no valid transition found for 'stop' from [currentState:stopped]: valid action(s) [start, unconfigure]

The Audit logs show that the deployments were indeed aborted:
10/04/12 19:37:57 PDT	jondoe	plan.execute	plan: 111, desc: Undeploy - Fabric [live] - PARALLEL, systemId: fd876b140f03e70e96658be282dc69c9a9144297	
10/04/12 19:37:34 PDT	jondoe	plan.abort	110	
10/04/12 19:34:52 PDT	jondoe	plan.execute	plan: 110, desc: Stop - Fabric [live] - PARALLEL, systemId: fd876b140f03e70e96658be282dc69c9a9144297	
10/04/12 19:34:31 PDT	jondoe	plan.abort	109	
10/04/12 19:34:11 PDT	jondoe	plan.execute	plan: 109, desc: Deploy - Fabric [live] - PARALLEL, systemId: fd876b140f03e70e96658be282dc69c9a9144297	
10/04/12 19:17:47 PDT	jondoe	plan.execute	plan: 106, desc: Stop - Fabric [live] - PARALLEL, systemId: fd876b140f03e70e96658be282dc69c9a9144297	
10/04/12 19:16:44 PDT	jondoe	login	

My guess is that our Ops started the deployment at 19:34:11, saw errors right away (the stop -> stop exception at 19:34:12) and so aborted at 19:34:31, which ended up with the exceptions seen in some agents at 19:34:36.

After that I see several steps, eventually a full undeploy (probably to get things back to a clear state), and then incremental deploys.

I was out not in the office when this happened, I'll check with our ops guys when they get in if the story matches.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

sodul
At this point I guess my concern is how we got into the stop -> stop exception. The deployment was triggered from the Glu console. Both Agents and console are 4.5.1.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

frenchyan
Administrator
This is my guess of what happened:

* you generate a plan at time = T: the plan contains the "stop" action
* you start executing the plan
* at some point during the plan execution, it reaches the step to stop... clearly by then time = T' (which is > T)

If between T and T' somebody stopped the mountPoint on the agent (which does not look like it is the case from the audit log), or your "monitoring" code detected a failure and moved the mountPoint into the stopped state (which you could check in the agent log file), then the stop action will fail because it is already stopped.

This is due to the fact that glu takes a "snapshot" of the state to generate the plan, then execute the plan. There is no guarantee that the state will remain the same between the generation of the plan and the execution, especially when the execution of the plan can take a long time (ex: a machine could entirely go down...). This is why you have safe guards in the code, like making sure that you can actually execute the action that was planned.

That being said, it is just a supposition. You should check with your ops team exactly the details of what happened. If none of what I described really happened, then I will investigate the "abort" procedure which may contain a bug.

Let me know
Yan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

sodul
Thanks for the replies. I confirmed with the Ops that it is likely what happened so you are dead on :-).

One Ops stopped our live environment and the other one deployed it a few minutes later. The deployment plan was 'prepared' before the stop was triggered. So they pretty much stepped on each other.

We'll makes sure from now on that only one person manage a fabric at a time (especially Live).

We never have the issue with our other fabrics since 99% of the time our Jenkins jobs are triggering the deployments automagically.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

frenchyan
Administrator
I can breathe again, glu is bug free LOL...

As we say, "shit happens" and I am glad to see that glu "reacted" properly and as expected. Yeah!

Yan

On Fri, Oct 5, 2012 at 8:54 AM, sodul [via glu] <[hidden email]> wrote:
Thanks for the replies. I confirmed with the Ops that it is likely what happened so you are dead on :-).

One Ops stopped our live environment and the other one deployed it a few minutes later. The deployment plan was 'prepared' before the stop was triggered. So they pretty much stepped on each other.

We'll makes sure from now on that only one person manage a fabric at a time (especially Live).

We never have the issue with our other fabrics since 99% of the time our Jenkins jobs are triggering the deployments automagically.



If you reply to this email, your message will be added to the discussion below:
http://glu.977617.n3.nabble.com/exception-during-shell-exec-calls-tp4025035p4025040.html
To start a new topic under glu, email [hidden email]
To unsubscribe from glu, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

sodul
Audit logs are underrated, that was one of my selling points here when I decided to switch to Glu. :-)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

RAHUL
In reply to this post by sodul
java.lang.IllegalStateException: no valid transition found for 'stop' from [currentState:stopped]: valid action(s) [start, unconfigure]

WHAT IS THE CAUSE FOR THIS ERROR..?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: exception during shell.exec() calls

frenchyan
Administrator
Loading...