Journalctl -- reclaim space on small mailinabox

I run my mailinabox on a small VPS with a 20G disk. The remaining space was getting tight, so I decided to go looking for some space and I discovered that /var/log/journal/ was consuming 1.8G. This was in logs only going back to March of this year which suggests lots of people may be losing a similar amount of storage.

I didn’t need to keep all the journals so I freed-up almost all the space with

journalctl --vacuum-time=10d

which preserves 10 days of journals. An alternative is to preserve by size with something like this

journalctl --vacuum-size=100M


This freed-up about 1.8G, a significant amount in my case. I believe many are running miab on inexpensive, small VPS so perhaps this can help.

Going forward, and assuming a similar volume of journals over the same period of time, I will have to repeat this work every four months.

1 Like

Oh wow I had no idea these logs existed. Great catch. We should add something to the setup to take care of this. Looks like /etc/systemd/journald.conf contains settings for this, currently:


which according to the documentation are the max total disk size and the max retention length (time). I’m not sure what is preventing the logs from staying around forever because Ubuntu has these defaulted to off, but in any case, we could try setting the retention length (MaxRetentionSec) to 10 days, as you tried, during Mail-in-a-Box’s setup. I think that’s a reasonable default.

What do you think?


Yes, it seems reasonable. I administer two miab servers and hadn’t checked these logs. Now, that is not what you want from a security perspective. However, considering how the miab solution is positioned (simple installation, browser admin, web-mail and IMAP, etc) the typical miab admin probably only ssh’s to the server for software updates.

Hopefully, a sysadmin who needs to monitor those logs over a longer period would either do it more regularly than 10 days or would have a backup strategy that includes the journalctl logs. Or they read the support forum, see this thread and raise an objection.

Give users an option :wink:

I have plenty of space, so I like to keep at least 1y
But many users will be running MIAB on VPS and ther disk space can be at premium …

Personally, as a user of MiaB not as a sysadmin I think that the logs do not need to be kept for long … maybe the 10 days proposed.

As a user of MiaB, I have referred to these logs ONLY when something has gone tilt.

We have to keep in mind the audience that MiaB is geared towards. Mainly the non-technical crowd.

The sysadmin types are going to be going through the code, so well documented code (which MiaB seemingly does well) noting to change this behaviour edit x should be sufficient as again, your typical user would not even know these logs even exists.

/var/log/journal# du -sh
4.1G .

Ouch! Thanks for the tip.

Vacuuming done, freed 3.7G of archived journals from /var/log/journal/

1 Like

10 days is more then enough!

1 Like

If updating the retention policy, the release notes need to mention the new, shorter period. Admins need a chance to know that is has changed.

Hi, same here, I just freed some gigabytes. Actually, I freed too many. The correct syntax seems to be

Journalctl --vacuum-time=10days

TVM for this!

2.7GB freed here.

I’d definitely appreciate a 10 day limit as other have suggested.

I’ve been clearing old logs myself with something like: rm /var/log/*.gz /var/log/*.1 -R
Had no clue journalctl --vacuum-size was even a thing!

Thanks for this :slightly_smiling_face:

I have run out of storage space. have flushed journals and logfiles. still out of space. had to resize server upwards to regain functionality. help!

Look at your storage directory. Use du to determine where storage is used.
One other culprit might be the nextcloud backup dir /home/user-data/owncloud-backup. This is created when nextcloud is updated. But once nextcloud is running properly, you can delete the contents of that folder, or e.g. save the most recent one.

Of course, if you have many users and/or mails, those will obviously also take storage :wink:

The backup directory was indeed the storage hog. Thanks!