log retention time period should not be hardcoded
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
atop (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
I'm presently running 16.04LTS. On that version atop's init script has the log retention period hardcoded to 28 days.
It would be better if the log retention period was set using a variable which could be modified in the /etc/default/atop file.
Here are two proposed patches that would resolve the issue:
--- /etc/init.
+++ /etc/init.d/atop 2017-09-09 17:00:36.972505450 -0700
@@ -26,6 +26,7 @@
WRAPPER=
INTERVAL=600 # interval 10 minutes
LOGPATH=
+RETENTION=28
OUTFILE=
PIDFILE=
SCRIPTNAME=
@@ -111,7 +112,7 @@
- [ "$1" = "_cron" ] && sleep 3 && find $LOGPATH -name 'atop_*' -mtime +28 -exec rm {} \;
+ [ "$1" = "_cron" ] && sleep 3 && find $LOGPATH -name 'atop_*' -mtime +$RETENTION -exec rm {} \;
;;
--- /etc/default/
+++ /etc/default/atop 2017-09-09 17:03:03.202163022 -0700
@@ -3,3 +3,4 @@
INTERVAL=600
LOGPATH=
OUTFILE=
+RETENTION=28
In Ubuntu 20.04 LTS the script /etc/init.d/atop calls /usr/share/ atop/atop. daily which does read /etc/default/atop and uses the variable LOGGENERATIONS=28. Systemd /usr/local/ lib/systemd/ system/ atop.service also calls /usr/share/ atop/atop. daily.
Confusingly, the file /etc/default/atop says not to use it:
# /etc/default/atop
# this file is no longer used and will be removed in a future release
Someone who knows better needs to decide how and where these configurable numbers should be set and either use the /etc/default/atop file or remove the misleading comment.