3

I've installed atop on a orangePi/RaspberryPi with only 40MB for /var/log.

It quickly filled my partition to 100%, I then purged it apt purge atop to remove it and its configuration files.

  • atop binary doesn't exist
  • its file in /etc/init.d doesn't exist
  • no systemd service called atop

Nevertheless, after a reboot, the /var/log/atop folder comes back full with the old atop files.

  • How can I completely remove it for good?

Edit:

$ ls /var/log/atop/
atop_20200822  atop_20200826  atop_20200830  atop_20200903  atop_20200907  atop_20200911  atop_20200915  atop_20200919
atop_20200823  atop_20200827  atop_20200831  atop_20200904  atop_20200908  atop_20200912  atop_20200916  atop_20200920
atop_20200824  atop_20200828  atop_20200901  atop_20200905  atop_20200909  atop_20200913  atop_20200917  atop_20200921
atop_20200825  atop_20200829  atop_20200902  atop_20200906  atop_20200910  atop_20200914  atop_20200918  atop_20200922

I removed atop on 2020/09/22, the last file. And it regenerates the same folder with the same files again and again after each reboot.

atop folders and files:

# find . -type d -name  *atop*
./usr/share/doc/libatopology2
./var/log.hdd/atop
./var/log/atop
./var/cache/atop.d

# find . -type f -name  *atop*
./usr/lib/arm-linux-gnueabihf/libatopology.so.2.0.0
./var/log.hdd/atop/atop_20200913
...
./var/log.hdd/atop/atop_20200906
./var/log/atop/atop_20200830
...
./var/log/atop/atop_20200826
./var/cache/atop.d/atop.acct
./var/lib/dpkg/info/libatopology2:armhf.symbols
./var/lib/dpkg/info/libatopology2:armhf.md5sums
./var/lib/dpkg/info/libatopology2:armhf.list
./var/lib/dpkg/info/libatopology2:armhf.triggers
./var/lib/dpkg/info/libatopology2:armhf.shlibs
Alexis
  • 607
  • 1
  • 15
  • 27
  • The files in there are usually called atop_YYYYMMDD. What dates are in use? – icarus Oct 03 '20 at 02:38
  • Old dates from 20200822 to 20200922. I `apt purged atop` on 09/22. It regenerates the old logs at each reboot... – Alexis Oct 03 '20 at 02:49
  • So no new logs being generated which is good. Does `/etc/atop` still exist? – icarus Oct 03 '20 at 03:06
  • yes, sorry I could have said that in my question. `/etc/atop` doesn't exist – Alexis Oct 03 '20 at 03:08
  • I found the problem... The OrangePi/RaspberryPi's ubuntu has `/var/log.hdd`, I deleted the atop folder and now it's fine. It seems `/var/log` is just a logical copy of the `/var/log.hdd` at each boot. – Alexis Oct 03 '20 at 03:12

2 Answers2

6

atop runs as a systemd service located in /lib/systemd/system/atop.service, and its executable is: ExecStart=/usr/share/atop/atop.daily

This atop.daily wrapper file configures the logging of atop , as well as the specific frequency of the logrotation of corresponding log files.

To prevent atop.service from being ran as that service at boot you can do:

sudo systemctl disable atop.service

Option 2

If you really cannot find the binary for atop under normal means, you may check /etc/default/atop which is the old way it was configured.

As the last resort you can run:

sudo grep -ral atop /etc/*

And look in the corresponding files

NetIceCat
  • 2,244
  • 1
  • 14
  • 25
  • As said in my post: `Unit atop.service could not be found.` and `cat: /usr/share/atop/atop.daily: No such file or directory`. – Alexis Oct 03 '20 at 02:50
  • no atop file under `/lib/systemd/system/` nor `/etc/systemd/system`. – Alexis Oct 03 '20 at 02:52
  • just added option 2 – NetIceCat Oct 03 '20 at 02:54
  • thanks but no file/folder named **atop** under `/etc/default/` and the grep command returns only `/etc/ld.so.cache` and `grep: /etc/motd: No such file or directory` – Alexis Oct 03 '20 at 02:56
  • can you run `journalctrl -r -g atop` and see if there is any mention of it. – NetIceCat Oct 03 '20 at 02:58
  • It shows only just the commands I just tried from your answer. `systemctl disable` and `grep -ral` and the `journalctl -r -g` – Alexis Oct 03 '20 at 03:00
  • What's interesting is that `ls` tells me the atop_* files were created at midnight. `-rw-r--r-- 1 root root 1.4M Oct 3 00:00 atop_20200823` – Alexis Oct 03 '20 at 03:04
  • ok, that tells me its ran by CRON and not systemd give me one sec – NetIceCat Oct 03 '20 at 03:08
  • your system is `sysvinit` so the reference to it will be in `/etc/rc.*` files. can you try `sudo grep -arHi atop /etc/rc.*' – NetIceCat Oct 03 '20 at 03:11
  • I checked, there is no cron job for sudo and my user. – Alexis Oct 03 '20 at 03:12
  • I found the problem... on embedded system such as orangePi and RaspbPi, somehow devs thought it was a good idea to make a copy of `/var/log.hdd` to `/var/log`. Thanks for your help. I'll still accept your answer because it's a good summary of all the solutions. – Alexis Oct 03 '20 at 03:14
  • 1
    Good find. You should definitely include your find as an answer though. It will really help others in the future – NetIceCat Oct 03 '20 at 03:16
0

On embedded systems such as OrangePi and RaspberryPi, Armbian uses log2ram to place the logs in the ram.

  • /dev/zram0 49M 756K 45M 2% /var/log

With /var/log being just a logical copy (located in ram) of the /var/log.hdd.

Removing any folders/files from /var/log removes them only from the RAM and doesn't change the files/folders written in the disk/sd card.

That is the reason why the folder was coming back after each reboot.

Deleting the folder /var/log.hdd/atop solved the problem.

You can also disable the log2ram service: systemctl disable armbian-ramlog.service

Alexis
  • 607
  • 1
  • 15
  • 27