Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 May 2002 11:08:13 +0400 (MSD)
From:      Maxim Konovalov <maxim@macomnet.ru>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        current@freebsd.org
Subject:   Re: newsyslog(8) should wait(2) for children
Message-ID:  <20020502110414.T15883-100000@news1.macomnet.ru>
In-Reply-To: <3CD0D898.A1A8B96D@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Terry,

On 23:11-0700, May 1, 2002, Terry Lambert wrote:

> Maxim Konovalov wrote:
>
> [ ... patch to wait for children, but do nothing with the result ... ]
>
> Yes.
>
> 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.

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.

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.

-- 
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru


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?20020502110414.T15883-100000>