glassfish
  1. glassfish
  2. GLASSFISH-16280

Killing DAS started with -v kills locally started instances

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: admin
    • Labels:
      None

      Description

      Anissa found this catastrophic bug. Easy to reproduce:

      1) Environment: DAS, 1 cluster with 2 instances

      2) start DAS in verbose mode
      asadmin start-domain -v

      3) start the cluster:
      asadmin start-cluster c1

      4) Verify all 3 servers are running

      5) Hit ^C in the DAS console

      6) See that ALL GlassFish servers are stopped.

        Activity

        Hide
        Byron Nevins added a comment -

        I tried removing the ^C handling behavior in non-Windows platforms (see the diffs below). I.e. after doing this, when you hit ^C, my code does NOT kill the spawned DAS process.

        Result: No change was noted. It did not solve the problem. All instances are killed.

        Show
        Byron Nevins added a comment - I tried removing the ^C handling behavior in non-Windows platforms (see the diffs below). I.e. after doing this, when you hit ^C, my code does NOT kill the spawned DAS process. Result: No change was noted. It did not solve the problem. All instances are killed.
        Hide
        Tom Mueller added a comment -

        On Unix (or Linux), a ctrl-C at the terminal sends the signal to every process that has the terminal as the controlling terminal. This includes all processes that are forked by processes running on that terminal. So this is a natural function of Unix-like systems.

        To get the instance to not exit, they have to be disconnected from the controlling terminal.

        Show
        Tom Mueller added a comment - On Unix (or Linux), a ctrl-C at the terminal sends the signal to every process that has the terminal as the controlling terminal. This includes all processes that are forked by processes running on that terminal. So this is a natural function of Unix-like systems. To get the instance to not exit, they have to be disconnected from the controlling terminal.
        Hide
        Byron Nevins added a comment -

        ^C maps to SIGINT. When I send a such a signal to DAS – the instances are NOT affected:

        kill -2 das-pid

        Show
        Byron Nevins added a comment - ^C maps to SIGINT. When I send a such a signal to DAS – the instances are NOT affected: kill -2 das-pid
        Hide
        Bill Shannon added a comment -

        I'm assuming in this scenario all the instances are running
        on the same machine.

        Note that the kill command sends the signal to the process,
        but ^C on the console sends the signal to the process group.

        I'm pretty sure there's another bug about this same general issue.
        Without native code, there's no good way to cause the sub-processes
        to run in a different process group. I think that makes this a
        "will not fix".

        The workaround is to not start the domain with -v.

        Show
        Bill Shannon added a comment - I'm assuming in this scenario all the instances are running on the same machine. Note that the kill command sends the signal to the process, but ^C on the console sends the signal to the process group . I'm pretty sure there's another bug about this same general issue. Without native code, there's no good way to cause the sub-processes to run in a different process group. I think that makes this a "will not fix". The workaround is to not start the domain with -v.
        Hide
        Byron Nevins added a comment -

        Here is the best solution IMHO.

        In the start-instance command:

        PSEUDO-CODE:

        if( (OS != Windows) AND (A console is attached))
        then refuse to start the instance. Emit a message about the reasons why.

        Then it is impossible to get into this bug condition!

        How to find out if a console is attached – the verbose flag is set. If it's set then there is a console. Period.

        Show
        Byron Nevins added a comment - Here is the best solution IMHO. In the start-instance command: PSEUDO-CODE: if( (OS != Windows) AND (A console is attached)) then refuse to start the instance. Emit a message about the reasons why. Then it is impossible to get into this bug condition! How to find out if a console is attached – the verbose flag is set. If it's set then there is a console. Period.
        Hide
        Nazrul added a comment -

        This looks like an improvement

        Show
        Nazrul added a comment - This looks like an improvement
        Hide
        Tom Mueller added a comment -

        Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

        Show
        Tom Mueller added a comment - Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issues was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

          People

          • Assignee:
            Joe Di Pol
            Reporter:
            Byron Nevins
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: