bg process into fg

bg process into fg

Post by Kenneth Van Camp -FSA » Wed, 02 May 1990 15:41:00



Is there a way to get a background process into the foreground in System V?
I know about C-shell's 'fg' command, but this won't work because (1) our
Silicon Graphics System V system doesn't support this aspect of the C-shell,
and (2) the process needs to be brought into the foreground after being
created from a different shell (i.e., I need to logout after creating the
background process).
        Here's the problem: I have a C program (and all the source code, so
I can consider C solutions as well as shell solutions) that does alot of
number crunching.  Typical runs take several hours, and sometimes as long as
a day.  Since I can't tie up my terminal during all that time, it naturally
has to be run in the background.  At this time I may logout.  However,
during the middle of a long run I would like to log back in and
interrogate/modify the run.  To do this, I have set up signal interrupts
(available via the normal Kill command) to alert the program that I wish to
interrogate the model.  Doing normal printf stuff, I never see the output on
my terminal because the process is background.  I need a way to bring it
into the foreground so I can interact with it.  
        Alternatively, I can just write to the tty device directly. I tried
this, and it worked for output but not for input. Here's an example, which
always reports num=0 and does not wait for user response. I'd appreciate
any suggestions.

/* testbg.c: test writing/reading from background process */
#include <stdio.h>
#include <sys/signal.h>

int     useio = 0;
main()
{
        FILE    *filout, *filin, *fopen();
        int     (*s16_svc())();
        int     num;

        signal (SIGUSR1, s16_svc);
        while(1)
                if (useio){
                        filout = fopen ("/dev/console", "w");
                        filin  = fopen ("/dev/console", "r");
                        fprintf (filout,"Enter a number:\n");
                        fscanf (filin, &num);
                        fprintf (filout,"Read number %d\n", num);
                        fclose (filout);
                        fclose (filin);
                        useio = 0;
                }

Quote:}

/* s16_svc: signal 16 service routine. Sets the global useio flag the first
 * five times it is called; the sixth time it stops the program.
 */
int (*s16_svc (sig))()
int sig;
{
        static int count = 0;

        if (++count > 5)
                exit(0);
        /* reset the signal so it works again */
        signal (SIGUSR1, s16_svc);
        /* set the global flag to use the i/o */
        useio = 1;

Quote:}


          Army Armament Research Development & Engineering Center
                        SMCAR-FSA-E  Building 329
                          Dover, NJ  07806-5000
                      (201)724-3334  (AV)880-3334
 
 
 

bg process into fg

Post by Larry McV » Wed, 02 May 1990 20:16:00



Quote:>during the middle of a long run I would like to log back in and
>interrogate/modify the run.  To do this, I have set up signal interrupts
>(available via the normal Kill command) to alert the program that I wish to
>interrogate the model.  Doing normal printf stuff, I never see the output on
>my terminal because the process is background.  I need a way to bring it
>into the foreground so I can interact with it.  

Well, how about this?  It's a little coding, but you said that was ok.

Set it up so that upon receipt of the signal, your process opens two
fifo's (I think you might need to be root to create these).  The job
will open one for reading, the other for writing.  But first close
0 and 1 (stdin & stdout) so that the file descriptors returned are
also 0 and 1 when you do the opens.

Now write a little program that does the same sort of thing - it opens up
the same two fifos.  Copy stdin to the write fifo, and everything read
comes from the read fifo.  

This may not be clear enough.... Anyone else want to take a crack at
this?  I'm guessing that this will work - I haven't tried it...



 
 
 

bg process into fg

Post by Keith Wacle » Wed, 02 May 1990 12:34:00



> Set it up so that upon receipt of the signal, your process opens two
> fifo's (I think you might need to be root to create these).  The job
> will open one for reading, the other for writing.  But first close
> 0 and 1 (stdin & stdout) so that the file descriptors returned are
> also 0 and 1 when you do the opens.

No need to be root; fifos are the only case of using mknod where you
needn't be the superuser (Well, one of the only cases anyway..).
Fifos are probably the most elegant way to handle the problem; here's
a simple program I use to create fifos on the fly, from the shell (sorry,
no shar..):

-------- Cut Here -------- Cut Here -------- Cut Here -------- Cut Here

/*
 *      fifo            make one or more fifos
 *      Usage: fifo name ...
 *      Creates a fifo for each argument.
 *      requires system V

 *      Use it as you like; sell it if you can!
 *      This has compiled an run successfully on:
 *              Pyramid 90x under OSx (att universe)
 *              AT&T 3B5 under System V 2.0.1
 */

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

char *myself;                   /* Name of this program */
char usage[] = "file ...";    /* possible proper args */

main(argc, argv)
    int argc;
    char **argv;
{
    int i;                      /* index of fifo names in argv */

    myself = argv[0];           /* our name */
    if (argc < 2) {
        fprintf(stderr, "Usage: %s %s\n", myself, usage);
        exit(1);
    }
    for (i = 1; i < argc; i++)       /* For each name on the cmd line */
        if (mkfifo(argv[i]) == -1) /* Make a fifo */
            perror(myself);     /* report any error */
    exit(0);

Quote:}

/*
 * mkfifo: path -> int
 * Side effect: creates a fifo in the file system at path.
 * Returns  -1 on error.
 */
int mkfifo(path)
    char *path;
{
    return mknod(path, S_IFIFO | 0666, 0);

Quote:}

-------- Cut Here -------- Cut Here -------- Cut Here -------- Cut Here

Simple as that.  I use fifos quite a bit, so I keep a couple in my ~/dev
directory.  Just don't let tar find 'em heh heh..

                                                Keith


University of Chicago         UUCP: ...ihnp4!gargoyle!sphinx!kdw1

1100 E. 57th Street
Chicago, Illinois   60637                 #include <disclaimer.h>