Q: How to preserve process state across logout/login?

[Wayne Throop]

> I use a network analysis program that takes 1.5 HOURS(!) of cpu time
> ...
>                          Restriction: I can't dink with the source...
> ...
> Michael L. Begeman              Microelectronics and Computer Technology Corp

There are two solutions that occur to me.  Both mean leaving the program
running in the background, with connections left so that you can connect to it
later.  One method (by far the simpler one) is applicable under System V.
It goes like this:

    To get the program rolling:
        $ /etc/mknod in p
        $ /etc/mknod out p
        $ nohup {your-command-line} <in >out 2>&1 &
        $ nohup sleep 40000 </dev/null >in 2>&1 &
        $ cat out &
        $ cat >in
    You are now talking to your program.  Now, you can wait until the
    program has gotten to a stable state (no IO going on), and then
    logout.  To get re-connected to the program when you login,
        $ cat out &
        $ cat >in
    To send EOF to the program, kill the sleep-ing process and the 
    "cat >in" process.  The other processes will come down gracefully.
    I have tested this method on a System V system with "cat" taking
    the place of {your-command-line}.

The equivalent solution for BSD4.2 is more complicated.  Using sockets instead
of fifos implies that you must either modify your program to use connect
instead of open, or you must write a program to mediate the connection to
the socket.  SO:  the Berkeley method means writing two programs:
    - One to fork off {your-command-line}, create and bind a socket (so
      that it can be found after logout/login), and use select to
      transfer a datastream from the socket to a pair of pipes that
      connect to the {your-command-line} process.
    - The other program connects to the bound socket, and uses select
      to transfer a datastream from the terminal to this socket.

I call these programs "create interactive demon", and 
"connect to interactive demon".  I propose these interfaces
(since I don't actually have these written).
    int_dem {socket-name} {command-line}
    con_dem {socket-name}

With these two programs, the scenario under Berkeley becomes

        % int_dem foo {your-command-line}
    After which you can either use con_dem immediately, or log out
    and use con_dem after a subsequent login:
        % con_dem foo

The behavior of these programs on encountering EOF on a pipe or
a socket is left as an excersize for the implementor.  BTW, if anybody
here comes up with the code for these programs, I'll post them.
-- 
Wayne Throopw at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw