Transfering the process state to another process

[Lloyd K L]

Hi,
   We want to have a program which cannot be terminated by the user (even  
admin). I think the only way to do this is to write a watchdog process. So  
there will be a master and a slave process, the master will be the active  
process, and the slave keep on watching the master. I case if the master  
is terminated, the slave become master and initiates a new slave process.  
But we need to transfer (or share) the process state of "old master" with  
the "new master" (So that the new master can continue form where the old  
master has stopped). Is this possible with shared memory?

Or is there is a better way?

Thanks,
   Lloyd

______________________________________
Scanned and protected by Email scanner
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[OvermindDL1]

On Thu, Nov 5, 2009 at 11:15 PM, Lloyd <lloyd@...> wrote:

>
> Hi,
>  We want to have a program which cannot be terminated by the user (even
> admin). I think the only way to do this is to write a watchdog process. So
> there will be a master and a slave process, the master will be the active
> process, and the slave keep on watching the master. I case if the master is
> terminated, the slave become master and initiates a new slave process. But
> we need to transfer (or share) the process state of "old master" with the
> "new master" (So that the new master can continue form where the old master
> has stopped). Is this possible with shared memory?

That might be hard, I can think of a number of ways to kill an entire
tree of processes.  Unless, say you are running on windows, you inject
code into the running process system or winlogin.exe and have that act
as your watchdog, or insert a low-level system hook to watch for all
events passing through windows and block any that try to destroy your
processes, but even all of that can be worked around.  Security at the
OS level, block access to the user would probably be the best bet
(easier and safer on *nix then Windows).  And of course, nothing helps
if they have physical access to the machine.  :)
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Nigel Rantor]

Lloyd wrote:

>
> Hi,
>   We want to have a program which cannot be terminated by the user (even
> admin). I think the only way to do this is to write a watchdog process.
> So there will be a master and a slave process, the master will be the
> active process, and the slave keep on watching the master. I case if the
> master is terminated, the slave become master and initiates a new slave
> process. But we need to transfer (or share) the process state of "old
> master" with the "new master" (So that the new master can continue form
> where the old master has stopped). Is this possible with shared memory?
>
> Or is there is a better way?

I imagine that any decent admin would tell you, politely:

"Please don't try and create a process I cannot kill when it goes
haywire, if you try I won't be running it in the first place."

Fundamentally though you can try and create a process like that but
you'll waste a lot of energy on something that you probably don't want
to do anyway.

Having said all that, ensuring that a process maintains some state so
that processing can be continued by a newly created process in case it
dies for some reason is a completely different matter.

How you store the state will depend on what kind of state we're talking
about, there's too many possiblities to try and guess at what you
require. Details please.

When it comes to gracefully restarting a process you will need to think
about a few things.

How will the watchdog tell when the current process is defunct?

How quickly after becoming defunct must the process be restarted?

What level of data "loss" is acceptable, and if we're talking about a
server with clients, what happens to the work they've done so far?

Again, this is a really huge landscape, and without knowing your
requirements any advice is probably going to be of limited value.

Regards,

   n
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users