This is an extension of previous question I had asked here{ python2 readLines.py & python2 readLines.py & python2 readLines.py & python2 readLines.py & python2 readLines.py &} | tee  output_file | java program I have been successfully using the script to serve my purpose(it may not be correct as per programming principles)I am executing the script as follows./script.sh &QuestionIs there any way to restart just the java program part of above set up?AttemptsAs soon as, the program was stopped, the entire script comes down.Tried a simple program in python reading from stdin and printing the data. Executed in one window of tmux session. Tried writing to stdout from another window in the session on the same host command prompt, which did not work (proving I need to read more about stdin as such). This was to see if writing the data to file + stdout and reading from stdin can be separated if at all.
Restarting program running in the background and still make it consume from stdin
bash;shell;tee
Probably not; restarting the standard input consumer requires the ability of that consumer to exec itself.#include <err.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <unistd.h>int main(int argc, char *argv[]){    char buf[1];    int ret;    int linenumber = 0;    fprintf(stderr, collect me some input...\n);    while (1) {        ret = read(STDIN_FILENO, buf, 1);       // unbuffered. inefficient        if (ret == 0)           // EOF            exit(EXIT_SUCCESS);        else if (ret < 0)            err(1, read failed);        write(STDOUT_FILENO, buf, 1);        if (buf[0] == '\n') {            linenumber++;            if (linenumber == 4) {      // restart ourself every four lines...                execvp(*argv, argv);                err(1, exec failed);            }        }    }    exit(EXIT_SUCCESS);}Which when run restarts itself every four lines:$ make execselfcc     execself.c   -o execself$ perl -E 'say line $_ for 1..8' | ./execselfcollect me some input...line 1line 2line 3line 4collect me some input...line 5line 6line 7line 8collect me some input...$ I'm going to go out on a limb and guess that a socket or message queue might better suit the need to randomly kill off and restart the consumer of output, as then the messages would (up to a buffer limit or with blocking...) stick around while the consumer process is being killed off and restarted. Or you could write a proxy of some sort that reads standard input and is tolerant of the subsequent java consumer being randomly not available, or to be able to more or less gracefully restart said consumer.(Note that with buffered reads, the consumer may need to take additional pains to process or somehow pass along whatever incomplete data got read by the buffered read but has not been dealt with at time of restart or exit...)