Date: Thu, 02 May 2002 01:04:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxim Konovalov <maxim@macomnet.ru> Cc: current@freebsd.org Subject: Re: newsyslog(8) should wait(2) for children Message-ID: <3CD0F321.546D0694@mindspring.com> References: <20020502110414.T15883-100000@news1.macomnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD0F321.546D0694>