Re: killking child processes

From: Irek (ireneusz.szczesniak_at_wp.pl)
Date: 06/20/05

  • Next message: David Schwartz: "Re: killking child processes" 
    Date: 20 Jun 2005 10:23:01 -0700

    Thanks for your reply, Michael.

    > Perhaps it would help if you paint a slightly bigger pigcture of what
    > you want to do, and why.

    I am developing a client-server application. The client is written in
    Java and connects to a remote computer with ssh. At the remote
    computer the connection is accepted by the ssh daemon, which starts for
    us an application that is the server.

    The client issues some commands to the server, so it's a kind of a
    login session. However, other clients can connect later to the same
    server. The server is supposed to die when the last client
    disconnects. The last client to disconnect doesn't have to be the
    client which started the server.

    The server creates some children to help perform the offered services.
    When the server dies I want to make sure that the children die too. I
    do not want the users to log in to the remote computer just to kill the
    running processes.

    > So, is your main program running arbitrary programs in it's children?

    They are not arbitrary. These programs are some commands, but I know
    in advance what they are.

    > If it is, then you probably have no definitive guarantees about being
    > able to kill them. You already identify one of them (leaving the
    > process group) that affects your solution.

    I understand that programs are albe to run away from my control. They
    can fork so that PID changes: the parent exits, the child keeps running
    under a different PID. They can change the process group, they can
    change their session. I understand these actions, and so I make sure
    that the children which the server spawns don't change their process
    group.

    > I assume here that you mean that the signal handler does the
    > kill(-pgrp, SIGTERM)?

    Yes, I do kill(0, SIGTERM).

    >> Every child process spawned by the main process will receive SIGTERM,
    >> unless the child process leaves the process group of the main process.
    >
    > And what do you think to do in that case? What I'm really meaning is:
    > you seem not to care too much about this case -- or do you? If you
    > don't really care about this case, why not?

    I know what the children do. Before I decide to incorporate some
    command into the server, I make sure that this command will not change
    its process group. Therefore I do not have to worry how to kill the
    processes which changed their process group.

    > And what if one of the programs you run is set-user-ID-root, and
    > changes its credentials in such a way that you can no longer kill it
    > (i.e., changes both its real and saved set-user-ID)?
    >
    > And what if the child programs make themselves immune to (i.e., ignore
    > or catch) SIGTERM?

    Yes, these are problems which I should consider if I ran arbitrary
    commands. However, I know that the commands which I use will not pose
    such problems.

    > I don't suppose that this solution is really any more reliable. What
    > if your STOPPED child is killed for some reason?

    I agree that the STOPPED child may be killed and then my whole scheme
    is for nothing. But this is a "safety system." If the main process
    dies before it gets to killing the child processes, there would be
    still some chance for killing the child processes. Indeed there is
    this chance because this STOPPED process might have not been killed,
    and it will take over the task of killing the children.

    Thanks again, Michael, for your detailed e-mail. I trully appreciate
    it.

    Best,
    Irek

  • Next message: David Schwartz: "Re: killking child processes"

    Relevant Pages

    • Return object twice from a remote call?
      ... server which contains a collection of child class. ... When the child collection grows, the client need to wait for a longer time, ...
      (microsoft.public.dotnet.distributed_apps)
    • Return Object Twice from a Remote Call.. Possible ?
      ... server which contains a collection of child class. ... When the child collection grows, the client need to wait for a longer time, ...
      (microsoft.public.dotnet.framework.remoting)
    • Re: HTTP attack looking for /sumthin ?
      ... What makes you think it's an attack? ... > Connection to child 4 established (server ... > philbo.stonecruz.com:443, client 205.221.242.1) ...
      (Incidents)
    • Re: Maintaining localization in a distributed environment
      ... what is the architecture between the child server and the central ... We have a smart client that connects through web services to the child site ... We don't have a connection between the central server and the child sites ...
      (microsoft.public.dotnet.framework.windowsforms)
    • Re: What doesnt lend itself to OO?
      ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
      (comp.object)