You were very close to the solution. Anaconda (the installer) is written in Python, so I went digging into the code.

Ultimately, it executes the script like this:

    rc = iutil.execWithRedirect(self.interp, ["/tmp/%s" % os.path.basename(path)],
                                stdin = messages, stdout = messages, stderr = messages,
                                root = scriptRoot)

A bit more digging and you can find iutil.execWithRedirect defined in 'iutil.py'. This function ultimately uses subprocess.Popen (a Python built in) to execute the command. It also tries very hard to get the contents of STDOUT and STDERR from the %pre script.

The code looks like this:

    #prepare tee proceses
    proc_std = tee(pstdout, stdout, program_log.info, command)
    proc_err = tee(perrout, stderr, program_log.error, command)

    #start monitoring the outputs
    proc_std.start()
    proc_err.start()

    proc = subprocess.Popen([command] + argv, stdin=stdin,
                            stdout=pstdin,
                            stderr=perrin,
                            preexec_fn=chroot, cwd=root,
                            env=env)

    proc.wait()
    ret = proc.returncode

    #close the input ends of pipes so we get EOF in the tee processes
    os.close(pstdin)
    os.close(perrin)

    #wait for the output to be written and destroy them
    proc_std.join()
    del proc_std

    proc_err.join()
    del proc_err

So, with what you have, you get past the proc.wait() and os.close calls by forking into the background.

proc_std and proc_err are threads that repeatedly call readline on STDOUT and STDERR. They keep reading until EOF is encountered. Since your script inherits the STDOUT and STDERR socket from the %pre script, they will never encounter EOF. Ananconda then hangs waiting for the thread reading STDOUT to exit (on the 'proc_std.join()') line, which never happens.

It's a very confusing issue, but ultimately a very simple fix. Instead of:

/bin/sh /tmp/rpm_watcher.sh &

use

/bin/sh /tmp/rpm_watcher.sh > /dev/null 2>&1 < /dev/null &

This ensures your script doesn't inherit STDOUT and STDERR, so Anaconda doesn't hang and the install can continue.

It's a little hard to diagnose, as you don't give source for myproc, but I suspect that your problem has something to do with "controlling TTY". I wrote a small shell script that just calls sleep 100. I ran it under nohup:

$ nohup ./sleeper > sleeper.out &

[1] 25305
-bash-3.2$ jobs
[1]+  Running                 nohup ./sleeper > sleeper.out &
-bash-3.2$ ps -l -p 25305
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S 429624 25305 18252  0 77   0 - 15961 wait   pts/0    00:00:00 sleeper

If you look at the ps output, you see a column named "TTY". At least some versions of nohup (the one I used above is from GNU coreutils, version 5.97, so relatively old). When I exited the bash shell from which I started sleeper, the TTY column changed to '?', meaning that sleeper didn't have one.

If myproc doesn't deliberately detach itself from it's controlling TTY, it's still possible to get things like a SIGPIPE signal if it tries to write to stdout. It seems to me other things are possible, but I can't recall or google anything up.

If you can find or compile "daemonize", you might want to try it. If myproc is compiled, you could modify the source to call the daemon(3) library function.