But that just limits /var/log/journal not the entirety of /var/log
Yep. The message and warn files only exists on Leap. On Tumblewwed these files does not exist and everything is written into journal.
You need to mount the top-level subvolume of the btrfs file system, e.g.: mount -o subvol=/ /dev/nvme1n1p2 /mnt.
1 Like
So ummm
Couldn’t get back to you because the forum limited my posts for 22 hours. Lovely new account limitation.
Your help really helped a lot! I swapped which kernel is being used when I boot, and the system partition stopped killing itself! I also found 2 files in the var folder which (one called messages and the other called warn), both totalling 100+ gb, so they’re the culprits. Can’t delete them though. They’re labled as system important files.
But I’ll figure it out! I want to thank you (and everyone else in the forum) for all the help. It really saved me quite a lot of time, and allowed me to finish rendering a project I was working on. THanks
No probs. Really glad I could help.
Yeah, you can’t delete those files - you need the truncate commands I mentioned earlier on:
As mentioned before, if I would have to get rid of these huge log files, I think I would look into logrotate:
I wish I could tell you from experience how to configure it properly but I never had a need for it.
Judging by the man page it seems like it can delete the /var/log/whatever files for you if you configure it in a way that it doesn’t have to do this (seemingy default) 5 weekly rotate.
Before I learned the official way to configure the journal, my hundreds of openSUSE installations suffered no apparent ill consequences of simply deleting the oldest journal files, just keeping those from recent days or weeks. My current configuration on 15.5:
# cat /etc/systemd/journald.conf.d/local.conf
[Journal]
Storage=persistent
SystemMaxFiles=10
RuntimeMaxFiles=12
ForwardToConsole=yes
TTYPath=/dev/tty10
Audit=no
# du -sh /var/log/journal
145M /var/log/journal
# ls -1 /var/log/journal/.../ | wc -l
10
#
Almost certainly, the problem is that /var is just a folder under / (root}
run
du -sxk /var/* | sort -rn | head -n 5 to see the top 5 folders and sizes and clean them up.
My guess would be /var/tmp
Don’t truncate you will have more problems… the journal file are a binary database since systemd.
Use journalctl to vacuum the old data. see this article : systemd: cleaning the space used by logs (journal) – Luca Ferrari – Open Source advocate, human being (fluca1978.github.io)
Hi thanks. You may be right as I’m no expert but I needed a quick fix to get my system back up and running again and truncate seemed the best tool for the job. However, it seems that your link refers to the journal log files (as does @mrmazda 's post). The problem logs for both me and @battlestoriesfan were messages and warn. Note @hui 's comment above (Root Partition mysteriously Full. Can't boot anymore - #24 by hui) about the differences between Tumbleweed logs and Leap logs.
Anyhow, the problem has resolved as it was just one kernel update that has been retracted.
So it’s been 3 days since. Using the other kernel has, effectively, gotten rid of the issue. my logs aren’t growing in size anymore, and my disc has stabilized.
But the messages and warn files in var/log are still gigantic (both of them combined is 100 gb), and the truncate commands don’t seem to affect them. If it’s ok that I bother you one last time, do you know a way that I can reduce the space on these files? I still don’t get how log files are so massive, and they are reducing my system hard drive to 30 gb of space.
What did you try to remove them so far?
sudo rm /var/log/messages?
And what was the outcome? did you try it with force?
Besides deleting the files, did you look into logrotate?
It’s preinstalled and preconfigured. SO, even after deleting th log files you apparently should run sudo logortate -f to set the logging back to normal.
I see some confusion in this thread between the journal in /var/log/journal and the two text log files messages and warn. As far as I know, with systemd, the files /var/log/messages and /var/log/warn can be deleted at any time. The actual system logs are stored under /var/log/journal.
logrotate will take care of messages and warn files in time, but I would just delete the huge files right away. They’re useless anyway.
If messages and warn are huge, the journal files are surely also huge. To shrink the journal, you want to use one of the “vacuum” commands for journalctl. For example, journalctl --vacuum-size=500M will shrink the journal down to 500MB. There are two other “vacuum” options for time and number of files. That’s the best way to delete journal files.
Yeah, haha…Everyone is confusing var/log/messages and var/log/warn with the journal. I don’t even HAVE a var/log/journal, so i assume that its a Tumbleweed situation. Instead it’s saved in run/log/journal. Using the jornalctl command clears 0 B of files, so the journal isn’t the issue.
I’m also having a hard time using logrotate, mostly cuz i put the command and nothing seemingly happens, and the OpenSUSE documentation is so bizarrely barren and vague that I don’t even know if i’m using it properly or if there’s something i’m missing.
I considered just deleting the messages and warn files, but they’re system binaries with a huge X on both of them, so i’m afraid to delete them. Don’t even know if the system will allow me to
It is not a Tumbleweed thing…you simply have no persistent journal enabled:
Either way, the journal doesn’t seem to be the large file taking so much space, It’s messages and warn, in var/log
If you are afraid of just deleting it, then move it somewhere else or rename it. If nothing bad happens (which will be the case) you see that you could delete it.
For logrotate, I tried running it and it works, but one needs to specify the config-fike i the command.
At least under tumbleweed it’s /usr/etc/logrotate.conf
Please check if you have it there in leap. If not then check if it’s in /etc/logrotate.conf
You can try and run it just as it is configured now (and probably run regularly anyways by a system service and a timer) with
sudo logrotate -f /usr/etc/logrotate.confThe option force (-f) will force a rotation on every logfile (as defined in the config-file) in /var/log. The putcome should be that you get /var/log/messages and warn with the date of compression in a compressed .xz-format and new (empty) log files should be created.
That should already safe some space and you can delete them or move them somewhere else if you really want to keep them.
If that doesn’t wotk you need to edit the logrotate.conf for /messages and /warn
To help with your fear, note that your journal in /run/log is deleted every time your turn off the computer. Those two files in /var/log contain the same information that gets deleted. Most of it is already gone! You’d just be deleting a copy of data that already has been deleted elsewhere.
They’re actually text files, so you can view them easily.
They’re marked as system files because they belong to root and don’t have world-writable permission. But, don’t be afraid to delete them. Or, move them as 404 suggested to make sure nothing bad happens.