daemon --makepid --fork

[Elan Ruusamäe]

to cut to the chase, looks like there's problem with using both of those 
flags together:

1. if RC_LOGGING=yes
the the pid written to pidfile is correct
but process started has fd=1 and fd=2 pipe which is disconnected after 
initlog exits. no process likes this, some abort when they receive SIGPIPE

2. if RC_LOGGING=no
the pid written to file is incorrect, it's sone actual_pid+N, where N is 1-2
stdin,stdout are /dev/null, so that is fine for most of the processes 
where we want to do "daemonize" for themselves.

for first problem, could solve this by >/dev/null 2>/dev/null in our 
makepid script
this means that initlog will not "capture" or "see" anything from those 
processes

for second problem, probably could use our makepid wrapper instead of 
using --makepid from start-stop-daemon.

i've committed 43f8f34 to rc-scripts repo where such behaviour could be 
analyzed

ps: know any good framework to use to write such tests for shell scripts?

ps2: usually i'd say lets rip out the RC_LOGGING=yes code, but seems 
RC_LOGGING=no isn't much used by other pld devs than me, so it's not 
probably most compatible and has unexpected results (like this bugreport 
about wring pid written). most horrible experience was causing lighttpd 
terminated with SIGKILL every time logrotate ran at night, fixed by this 
commit:

commit 6154a5cecca4c7cf7252a230f81d2fa913c0bfab
Author: Elan Ruusamäe <glen at pld-linux.org>
Date:   Wed Dec 5 20:54:15 2012 +0000

     killproc: improve experimental start-stop-daemon based killing.

     do not send --retry, in case we specify a signal to kill (usually HUP)
     as processes do not usually exit (remove their pid from pidfile) if 
they receive HUP


     svn-id: @12603

ps3: don't bother replying something poisonous about why don't i go use 
systemd.

-- 
glen