1

On Raspbian stretch, every day at 6:30 am, an alternatives.tar.0 file is created in the /var/backups folder, leaving 0% free space. So far, I have not been able to figure out what is doing this or why. Crontab shows there are no jobs scheduled.

This is a pi-zero with an 8G card. Running a node app that writes to Sqlite3 a small amount of data every minute. Ran fine for a few weeks then stopped. The data amounts to about 30k/day and I had 3G available.

Found that it stopped because Sqlite returned a disk full message. I freed up about 500M by deleting some apps and the next day it was full again. Then found the culprit, a file (just over 3G) named alternatives.tar.0 in /var/backups.

Inside that file were some small files like mt, rcp, jarsigner, desktop-background, and one huge file (8.5G) named jdb.

Many searches have turned up very little to nothing about the alternatives.tar or jdb files. I did read about the Debian alternatives feature but it doesn't seem related.

Any ideas are welcome!

1
  • The file is not created daily, it is updated daily, and rolled over monthly. Normally the directory is small (mine is 4MB). The question would be better on a Debian forum. JDB suggests the Java Debugger.
    – Milliways
    Mar 2 '19 at 0:09
1

I suppose you should reinstall openjdk-11-jdk-headless or whatever java package you have installed. jdb is not supposed to be 8GB in size (the whole OpenJDK package is around 170 MB), and its "copy" from /etc/alternatives (which is being backed up) should be a symlink with a size under 100 bytes.

0

Bit late to the party but better lae then never I guess ;)

Your culprit here is /etc/cron.daiky/dpkg , thisnis a backupscript which takes the last 7 dpkg databases and mashes them into one huge tar file.

You can just remove the tar file at this point as it is eating up all your space and is just a backup.

You can do two things to fix this and I reccomend doing both.

First lets make sure no new file can be created:

touch /var/backups/alternatices.tar.0

chattr +i $_

This crates the file and makes it immutable, not even root can remove until you run chattr -i on the file.

Then relocate your dpkg backup script:

mv /etc/cron.daily/dpkg /root/

The reason for doing both is that I suspect that in a future upgrade the dpkg file might be recreated.

1
  • 1
    Please fix the spelling. There's really no hurry answering a one-year-old question. Jan 27 '20 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.