Unfortunately, it doesn't work for commands like gedit, gvim or firefox, that
interpret the " & wait $!" suffix as their parameter. Shell scripts fork
well. I was trying the solution Thomas has proposed yesterday (using the same approach as
rhq-wrapper script does), but afaik, there is no way to handle user input and relay it to
the process in the background and vice versa.
jk
----- Original Message -----
From: "Charles Crouch" <ccrouch(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Monday, February 18, 2013 4:49:56 PM
Subject: Re: AS is killed if the agent is killed (provided it was started/restarted by
the agent)
So what is the magic change?
----- Original Message -----
> I've implemented something that solves the issue. I've added a flag
> called "separatedFromParent" on ProcessExecution class and if user
> sets it to true it, surprisingly, separates the process from the
> parent process without loosing the exit code and/or streams.
>
> I want to make a hangout on G+ about it today at 17:00.
>
>
> jk
>
> ----- Original Message -----
> > From: "Larry O'Leary" <loleary(a)redhat.com>
> > To: rhq-devel(a)lists.fedorahosted.org
> > Sent: Thursday, February 14, 2013 11:02:03 PM
> > Subject: Re: AS is killed if the agent is killed (provided it was
> > started/restarted by the agent)
> >
> > On Thu, 2013-02-14 at 13:39 -0500, Jiri Kremser wrote:
> > > > If this happens when you run the agent using the recommended
> > > > mechanism (rhq-agent-wrapper.sh) then I agree this is a
> > > > problem.
> > > > If this is true, we need to know this and fix it.
> > > > So, if someone starts the agent via rhq-agent-wrapper.sh,
> > > > that
> > > > agent starts an AS7, the user then stops that agent, does the
> > > > AS7 die? If so, that's a problem.
> > >
> > > Neither sending the SIGINT to the agent started by
> > > rhq-agent-wrapper.sh nor sending the SIGKILL stops the AS7.
> > > Because the rhq-wrapper is separated from the agent
> >
> > Okay. If this is the case then perhaps this does reduce the
> > impact
> > of
> > this issue. However, I do not think it reduces the severity of
> > the
> > issue
> > or mean that this is not a bug.
> >
> > > > That is not the same thing. You are executing the code within
> > > > the
> > > > shell.
> > > > You are not forking a process. Only creating a child shell
> > > > within
> > > > the
> > > > running shell. If that is what we are doing, then that seems
> > > > to
> > > > be the
> > > > flaw.
> > >
> > > I think it is the same as what we do in our environment. The
> > > only
> > > way of forking a process in bash is the & as far as I know, we
> > > don't have any C code doing fork().
> >
> > Agreed. I am not saying it is not the same as what we are doing.
> > I
> > am
> > saying that what you described is not the same as what I was
> > referring
> > to. I can start processes or have init start processes without
> > the
> > concern or risk killing my terminal or the init service resulting
> > in
> > everything be stopped.
> >
> > What you are referring to is executing processes within a thread
> > in
> > the
> > foreground. Perhaps that is a limitation of Java but shouldn't
> > change
> > the fact that such a limitation introduces a critical flaw in how
> > plug-ins control the life-cycle of a resource they manage and by
> > using
> > such functionality, you are now exposing all your services to the
> > potential of ultimate termination by the agent in an uncontrolled
> > manner. In other others, the only option I have is to use RHQ or
> > not
> > to
> > use RHQ. There is no happy medium other then just telling users
> > not
> > to
> > do something and hoping that everyone remembers that for ever and
> > no
> > new
> > administrators get added to the team. Essentially saying that it
> > is
> > human nature and an accepted standard that unrelated processes
> > don't
> > share the same life-cycle.
> >
> > >
> > > > All processes that have been forked from their parent will
> > > > not
> > > > receive
> > > signals from their parent.
> > >
> > > agree, or if the signals are intercepted by traps or a signal
> > > handlers (for JVM).
> > >
> > >
> > >
> > > There is a JVM option -Xnosigchain for disabling the JVM signal
> > > handler chaining on IBM JVM, on the Oracle's JVM there is -Xrs
> > > option for that. I wouldn't do that. It would disable our
> > > ShutdownHookMechanism.
> > >
> > > Other option is to implement our own SignalHandler
> > > (
http://pastebin.test.redhat.com/127934). I am playing with it
> > > right now.
> >
> > >
> > >
> > >
> > >
> > > . The default signal handler can be replaced
> > > IBM java specific, for oracle there is -Xrs
> > >
> > > not good idea
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "John Mazzitelli" <mazz(a)redhat.com>
> > > > To: rhq-devel(a)lists.fedorahosted.org
> > > > Sent: Thursday, February 14, 2013 4:32:27 PM
> > > > Subject: Re: AS is killed if the agent is killed (provided it
> > > > was
> > > > started/restarted by the agent)
> > > >
> > > > > There are other ways this could happen. For example,
> > > > > platform
> > > > > level
> > > > > monitoring systems may decide to restart this agent by
> > > > > sending
> > > > > it
> > > > > the
> > > > > SIGINT signal. From the sounds of it, this too would cause
> > > > > the
> > > > > issue
> > > > > whether the agent is in the foreground or background?
> > > >
> > > > If this happens when you run the agent using the recommended
> > > > mechanism (rhq-agent-wrapper.sh) then I agree this is a
> > > > problem.
> > > > If
> > > > this is true, we need to know this and fix it.
> > > >
> > > > So, if someone starts the agent via rhq-agent-wrapper.sh,
> > > > that
> > > > agent
> > > > starts an AS7, the user then stops that agent, does the AS7
> > > > die?
> > > > If
> > > > so, that's a problem.
> > > > _______________________________________________
> > > > rhq-devel mailing list
> > > > rhq-devel(a)lists.fedorahosted.org
> > > >
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > > >
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel(a)lists.fedorahosted.org
> > >
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> >
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel