1 of 1 people found this helpful
jblackston, there are some other discussions of this problem on this forum. Basically, your /var/log/journal folder is getting filled up. Fix with rm -rf /var/log/journal/*
1 of 1 people found this helpful
Others can probably answer this better than me, but here is what I have run into.
1) Log files eating up all of the room. Several threads have talked about this. When I run into this I usually do something like:
rm -r /etc/log/journal/*
2) I have run into this a few times (latest was today). I setup the machine, I setup to to Alext's repos, I also setup to be able to upgrade my MRAA installs, and do something like:
The upgrade will upgrade lots of stuff, including maybe kernel. This is where I ran out of space today. There have been a few threads talking about the fact that the boot partition is not created to it's full size, which can cause these issues. I followed AlexT's instructions on how to resize the partition that is part of his bllog How to install a kernel from my repo onto Edison with the official image
Hope that helps
I have discovered that the edison_config.service is writing 471 bytes every 10-11 seconds to the journals. This equates to 6.25M every 3:08 hours. If you have your Edison configured and it is no longer needed you can issue a console command systemctl disable edison_config.service. It would default back to on if you every reflash your Edison. You will have to change directory /var/log/journal and rm/rmdir your older unneeded files.
I wouldn't recommend doing "opkg upgrade" on my repo, it's not the use case I'm targeting for, so it's not tested and may cause glitches.
Generally I'm targeting the repo for the case of installing specific packages, maybe even the kernel (just wrote up an article on that recently), but not such a blanket one as "upgrade" does.
Additionally, try adding the below configuration options into /etc/systemd/journald.conf, that should limit the maximum disk space used by logs.
I am running build_68 (and possibly the build is a contributor) but I have mine at SystemMaxUse=25M and it over ran that constraint --> 80M or so from continual journal entries (471 bytes every 10-11 seconds) by configure_edison.service.
Do you have "Storage=persistent" in the config? It's not like I'm suggesting edison_config isn't polluting the log, by the way, but with SystemMaxUse it shoudn't run significantly over that for this situation and I'm trying to find solution, because it nags me as well.
There's one more specific thing that happens during the reboot, which creates a broken copy of the log file behind (with ~ in the file name), that also contributes to the storage consumption, but that's a separate thing I want to tackle later.
Storage=persistent and SystemUseMax=25M .. and journals chewed out 130,000 1K blocks (df /)
I noticed as well, a 6553600 byte journal that gets created before the network timesync comes in, then abandonded by a journal at proper time.
Ah, I see, interesting. There was a bug in journald back in 2013 which had the same symptoms, but I expected it to be fixed in Yocto 1.6, but maybe it's not... I'll check it out in more details later on, it's annoying.
since Edison is configured, I simply used systemctl disable configure_edison.service to prevent the over logging.
Yeah, that's sort of an immediate solution, but I want to get to the bottom of this, because it should obey those limits set in a file