But really, crond is expected to be a long-running process, and it is a process dispatcher. Not protecting its process table from undue growth by an unexpected zombie pile-up is Not A Good Idea.
The unexpected zombie pile-up is not on crond, which was not designed to be pid 1 and should not have that expectation placed upon it. Processes designed to be pid 1 have more stringent requirements than usual: for instance, they must function when they don't have a writable filesystem made available to them, and they must never die, even when having problems or running out of resources. crond does not meet these requirements and is unsuitable as pid 1. Running a container with crond as pid 1 is not a reasonable use case, because it may fail at any time, for other reasons than the zombie pile-up, and the container is not stable. In other words, this isn't a bug in crond, however using crond as pid 1 in a container *is* buggy, and the report is invalid. Don't do that. There are a lot of lightweight inits suitable as pid 1 in containers: tini, dumb-init, s6-overlay, to only name a few - or even busybox itself, which can run as init and supervise a unique crond process via a tailored /etc/inittab. That said, unless it's an invasive change (which isn't the case here), reaping bastards (children you don't know you have) is not bad practice, and does not hurt. I'm not opposed to the patch since it's very light, except that it could help perpetuate the harmful misconception that crond is suitable as pid 1. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net https://lists.busybox.net/mailman/listinfo/busybox
