Issue #208 already fixed is kind of bad on Debian 10 and Ubuntu 20.04 as they only have the older 2.0.2 in the main repo and never upgraded to 2.1.0 to get these fixes. The result is that recaplog is basically not working to clean up logs at all, causing /var/log/recap/ to fill up over time.
Does anyone in the recap project have an idea how we ask Debian / Ubuntu to promote the newer 2.1.0 into their backports repos so that users can get this upgrade and the fixed recaplog issue?
Edit: we dug up an older Ubuntu 20.04 installed last year, it's kind of out of date with the latest packages and it seems to be working - recaplog 2.0.2 doesn't exit on that SIGCHLD. A newer/fresher installed U20 device with the same version of bash and recaplog doesn't work as it's exiting on the SIGCHLD trap when it runs $() subshells, so it's possible there was an underlying library or ?? changed that's caused the problem to roll up the stack. Bit of a "wonder what it is?" problem now.
Issue #208 already fixed is kind of bad on Debian 10 and Ubuntu 20.04 as they only have the older 2.0.2 in the main repo and never upgraded to 2.1.0 to get these fixes. The result is that recaplog is basically not working to clean up logs at all, causing
/var/log/recap/to fill up over time.Does anyone in the recap project have an idea how we ask Debian / Ubuntu to promote the newer 2.1.0 into their backports repos so that users can get this upgrade and the fixed recaplog issue?
Edit: we dug up an older Ubuntu 20.04 installed last year, it's kind of out of date with the latest packages and it seems to be working - recaplog 2.0.2 doesn't exit on that SIGCHLD. A newer/fresher installed U20 device with the same version of bash and recaplog doesn't work as it's exiting on the SIGCHLD trap when it runs
$()subshells, so it's possible there was an underlying library or ?? changed that's caused the problem to roll up the stack. Bit of a "wonder what it is?" problem now.