Bug 25269

Hm, I can only reproduce this behavior *while running under strace*.
It appears strace affects the behavior somehow.

Interesting. Perhaps strace is confusing initlog's sense of when children exit. But
here's the thing: if, as root, I run

initlog -q -c 'sh -c "/bin/echo hello ; sleep 1 ; /bin/echo world"'

I see hello and world get logged, so clearly -q is not causing the messages to be
suppressed. On the other hand, if I do the same thing as a non-root user, the log
messages do not appear. If I omit the -q option as a non-root user, the messages
do appear.

So I think there's something screwy in the logic somewhere. Perhaps -q is only
broken when running as root.

Checking the open file descriptors from the proc filesystem of processes running
under initlog -q (as a non-root user) I see 1 and 2 still connected to a pipe, rather
than /dev/null.

They should be connected to a pipe; it only supresses the output
from being *displayed*.

That's fine, but what I'm saying is that that is bad design as it means initlog has to stay
around for the entire duration of the child's lifetime. If it connects the child to /dev/null when
invoked with -q it can exit at will without endangering a critical process.

I encountered this when running a slave nameserver, as it was breaking zone transfers.
I didn't start running initlog under strace until I had already established that something
was very wrong. I hope it is clear this is a real problem.

The design is altogether *intentional*. It's extremely hard to
log the output of the command if you connect its output to /dev/null;
if you don't want to log the command's output, don't run it under
initlog.



*** This bug has been marked as a duplicate of 15973 ***

Tell that to the people who wrote the daemon() function in
/etc/rc.d/init.d/functions. I get the feeling you didn't really read
what I wrote at the beginning of this ticket. So I'll recap.

The daemon() function, as shipped by Red Hat, runs all
daemons under initlog with the -q option.

What is the point of connecting stdio to pipes when you
are running it with -q? Presumably, as you just stated:

> it only supresses the output from being *displayed*.

you aren't interested in logging the output in that case.
Meanwhile, you are killing named-xfer every time (except
the first) it runs. Why bother with pipes when you're throwing
it all away anyway? What is the *intent* in this scenario?

You're misunderstanding what it's for; we aren't throwing the output
away, we are logging it all (if it doesn't log, that's a different problem).
We just aren't displaying it.

-q means "don't show me the output if the command runs successfully". In
all cases the output is still logged, though.

How are you starting named? Did you change the initscript at all?

The named startup script is unmodified. /usr/sbin/named
itself has been replaced with a shell script that does:

#!/bin/sh

exec /usr/sbin/named.real -t /path/to/chroot/hierarchy "$@"

I.e., it invokes the real named with an additional -t option.
This strategy has enabled me to keep a chrooted named
updated without having to tweak the init script.

In view of your explanation of the -q option, I'll accept this
as a duplicate of 15973, as you had categorized it. Is there
any solution pending?

My workaround was to redirect stdio in my shell script to
/dev/null, so named-xfer doesn't commit suicide.

No solution pending yet; I'll know more once I reproduce it
on a system here.

*** This bug has been marked as a duplicate of 15973 ***