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) {
I found a bug in the code as described in this issue:
https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1779583
The bug would not prevent the error you're seeing, however, there is a
second fork() which, if it fails, will block that part of cron, which
would therefore leak. So if it happens "on
I ran into this as well, with the same host's cron daemon reaching ~8GB
RSS memory after a month.
--
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
** Tags added: trusty
--
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:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cron (Ubuntu)
Status: New => Confirmed
--
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
