Maxim Konovalov wrote:
> > [ ... patch to wait for children, but do nothing with the result ... ]
> >
> > Why not just set the signal handler for the child process
> > termination to "ignore", so that the child processes do
> > not become zombied in the first place, so it's not ever
> > necessary to do a useless loop whose only purpose is to
> > reap zombies without examining their exit status?
> There are two purposes:
> a) reap zombies,
> b) exit after all children have done only.
> In the current implementation newsyslog(8) forks and execs gzip(1) or
> bzip2(1) and exits immediately. If a log file(s) is big enough the
> compress_log() process(es) will work after newsyslog's death and there
> is no clear way to get know when it(they)'s done.

Your (a) is statisfied with either approach.

I don't understand why you think (b) is a requirement.

> OpenBSD:
> a) SIGCHLD signal handler: waitpid(2) loop, do not examine "status",
> b) the same waitpid(2) loop before exit(2).
> I do not think we need a) at all. newsyslog forks/execs all his
> children and enters into the reap loop like SIGCHLD signal handler
> does.

The point of this is to not reap until you have to; the default
case will be no reaping necessary, so you are adding overhead
unnecessarily by atttempting to reap non-existant children.

> NetBSD:
> a) waitpid(2) for a child right after fork/exec,
> b) examine "status" and print an exit code.
> As you see, NetBSD newsyslog serializes fork/exec and there is only
> one gzip process at the same moment. We can take this way but IMHO it
> will be a POLA violation.

I think the reason NetBSD does this is that there is a
sizeof(uncompressed) + sizeof(compressed) window during the
operation itself.  If you run out of disk space while this
is going on, it's a bad thing.  So serializing gets you:

i.      No contention for the remaining disk space between
        more than one process

ii.     The ability to not attempt things you know will fail
        (average compressability will remain constant over
        a given log file contents, statistically)

iii.    A reduction in the maximum instantaneous CPU load
        committed to the newsyslog operation (by serializing,
        the total load is spread over time)

There are arguments for both approaches, but if you want to
wait for the operation to complete, the OpenBSD approach is
better than a reap-loop.

If you are going to interlock, then interlock.  If you aren't,
then don't bother explicitly reaping.

Realize also that the zombied processes shouldn't hang around
forever: newsyslog isn't a daemon.  And the zombied processes
only take up 64 bytes of memory until they are reaped on the
exit of newsyslog.

Not that I'm arguing that the processes shouldn't be reaped,
or at least ignored.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to