Maxim Konovalov wrote:
> > > 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.
> Let's imagine:
> # /usr/sbin/newsyslog && ./make_something_with_compressed_log
> newsyslog exited but there are several compress_log() processes are
> still running and make_something_with_compressed_log will get a
> half-compressed logs.

You probably meant to say "half the logs compressed", not
"half-compressed logs".

As far as "half-compressed logs", where a single log file can
end up partially compressed -- that can't happen.  If it fails
to successfully compress, gzip will revert and not compress the

Overall, allowing multiple processes, and waiting for them to finish
still doesn't accomplish anything:

        "exited" != "exited successfully"

If any process has failed to exit successfully, then you can end
up with half your logs compressed and half not.

If you do the NetBSD approach and serialize, you actually *do*
accomplish something: you guarantee that the list of files will
be processed in a specific order, and if one fails processing,
no subsequent processing will be attempted.  This is the most
recoverable case, in terms of script based automatic recovery.

> > > 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.
> As you see, OpenBSD has (a) *and* (b).

You misunderstand.  The reaping should be accomplished in the
SIGCLD handler.

> > 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.
> Again, OpenBSD has a reap loop.

A reap-loop in a SIGCLD handler is a better idea.

I still don't understand why you want to delay exiting of the
parent until the child processes are finished.

I also don't understand why you want a zombie to pile up for
each process, until you hit your "reap loop", rather than
handling them as you get SIGCLDs.

-- Terry

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

Reply via email to