Actually, an immediate fix for you guys may be to make sure that there
is some *input_data. I have no clue what that means in terms of
administrative setup, though. But maybe someone else can help in that
area. The really bad statement looks like this:
if (*input_data && fork() == 0) {
... // handle input_data
exit(0);
}
children++;
The children variable counts the number of successful fork()'s. Only in
this case (1) the fork() is never checked for failure and (2) if
*input_data is false, then the fork() does not even happen. Yet, either
way, children is always increment! Ouch! As an administrator, it may not
be possible to always make sure there is something in input_data. But it
is not unlikely that this is what makes many cron fork() wait forever
and thus increase memory. I have not had that problem on my end, I was
just reading the code for fun...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1702785
Title:
High memory and "can't fork" on heavy long-lived cron daemon
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1702785/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
