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

bootdebianinit.dlinuxrc.local

I have a peculiar issue when starting ongoing(service-like) processes from either full blown init.d script (SysV style) or a simple one-line call from rc.local file like so:

su someuser -c "/home/someuser/watchdog.sh &"

Where watchdog.sh contains this:

#!/bin/bash

cd /home/someuser

until ./eventMonitoring.py
do
    echo "Program crashed with exit code $?. Starting again..." >&2
    sleep 1
done

I'm always left with one additional process in the processes list: 

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

If I launch it from my init.d script(source: https://github.com/ivankovacevic/userspaceServices)

I get the same process but it is startpar -f — userspaceServices

What the heck is that process? Why is there no mention of -f argument when looking at the man page of startpar? What am I doing wrong in terms of starting a process at boot as another user, that this strange startpar process needs to be left(or started) also? Why is that process not present for any other init.d script?

Can someone please help me shed some light on this subject?

Note: My system is Debian Wheezy 7.4.0

UPDATE !
I've opened a new question on stackoverflow to discuss startpar behaviour from a programmers point of view:
https://stackoverflow.com/questions/22840360/figuring-out-what-startpar-c-sysvinit-is-doing

Best Answer

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.

Related Topic