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 <g...@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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
