@
Curaga:
Without digging through the sources for both acpid and start-stop-daemon, the term "sure" (as to whether or not it's StdErr versus StdOut)... not really sure a'tall.
After experimenting for the past hour and change (skipping start-stop-daemon, tinkering with logging, etc.) the following were required to put a cork in acpid:
1) The --quiet flag in start-stop-daemon
must be the
first in the command line. Anywhere else and it seems to be ignored.
start-stop-daemon --start --quiet --exec /usr/local/sbin/acpid
Does not work to prevent output
start-stop-daemon --quiet --start --exec /usr/local/sbin/acpid
Works (to a
degree with acpid, completely elsewhere for the few I tested)
2) Adding
-l /dev/null to the command line when launching the binary sends
all logging to oblivion... which has its down-side as well.
For
my needs in this situation, acpid is only being used to detect the power button, so killing the logging/output altogether is of no extreme consequence.
Based on how it reacted, my theory is that acpid itself is not being detached/disowned from tty0 and since the terminal count in TCL is (by design) limited to the one on boot, it's likely programmed to attach itself to the last terminal on the list for output - or at least that is how I would have done it
Then again, had I designed acpid, I would have programmed in a switch to disable screen output entirely.