startpar process left hanging when starting processes from rc.local or init.d

My investigation further into this led me to a solution. So now I know how to do it correctly, but I still do not understand why startpar behaved like it did. So if anyone is willing to step in and explain that, I'm more than willing to accept that answer than this one.

Basically the problem was that I called the scripts without redirecting(or closing) standard input, standard output and standard error to a file or to /dev/null and for some reason startpar("used to run multiple run-level scripts in parallel") process, which to my understanding is the one which launches other processes during boot, got blocked on this script of mine because of that. It did launch my script, but it itself did not finish running and was left at stage shown in the processes list as:

UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
root      3048     1  0  1024   620   1 20:04 ?        00:00:00 startpar -f -- rc.local

Source code of startpar is here: http://svn.savannah.nongnu.org/viewvc/startpar/trunk/startpar.c?root=sysvinit&view=markup

I skimmed through it and made my initial analysis in a new question that I posted on stackoverflow. Find the link in the UPDATE I added to my question here.

The final solution that I used is this:

su someuser -c "nohup some_script.sh >/dev/null 2>&1 &"

su - substitute user identity to someuser
-c - su argument to run specified command
nohup - Run a command immune to hangups. To prevent cases where parent process will terminate the child process. Added here just in case. But actually has no effect in my particular case. Whether it is needed depends on the environment(check shopt)
>/dev/null - Redirect standard output to nothing, basically disabling it.
2>&1 - Redirect standard error(2) output to standard output(1), which is redirected to null
& - detach to background, this will redirect standard input also to /dev/null.

Looking at file descriptors of other know daemons running on my system I see that redirection to /dev/null is a common thing. And only some daemon processes have actually fully closed stdin, stdout, stderr. Which could be for example achieved by this:

su someuser -c "some_script.sh 0<&- 1>&- 2>&- &" 

In a practical sense it is all the same and it is what is needed(either option) to cleanly detach a process as a background daemon.