Frostbyte

I guess that will give me the peace of mind that I need. Good thing I kept configuration backups! Thank you for the assistance.

Instantly, sadly..

I see, thank you for the insight so far. I'll see what I can do with it and hopefully I will have something to share back.

Everything is commented out here too, but from what I know - commented values are the default ones, unless manually overridden. In the case of "Storage" it's comment reads "auto", thus means that it'll collect journals if it finds a /var/log/journal folder, otherwise it will do nothing. The manual entry for journald.conf describes the configuration under /etc and I have already perused it. I tried to stop journal collection by setting the Storage value to "volatile" and "none", each without success. After a reboot it will be filled to the brim again. The odd thing here (at least for me) is that when I delete the contents of /var/log/journal but not the folder itself, journal collection will halt. So I have to do this every reboot or set up a crontab (too hacky of a solution for my liking). The underlying folders and files appear to be random hexadecimal jibberish, how do we know where they originate from? Also, I suppose I will ask this too: We obviously run a risk if we turn the journal off and thankfully I have my device on a UPS.. but even these can go out during long outages. I remember that the TinkerBoard survived plenty of power outages and crashes when I had it with the Xenial image, that one had it's journaling off by default, no? I always keep backups; but I'd rather avoid accidentally/unwillingly tearing it a structurally superfluous new behind, as my reasoning to use them.

Excuse me if I'm being ignorant at this point, but if the journal is supposed to be off in the first place, then do it's contents really matter at this point? How can I turn it off if it's not obeying the configuration? Am I missing something? Do I have to turn it off somewhere else? Also, I will need to do some RTFM before I'll be able to decipher the contents, any pointers will be most welcome.

No one? Or at least an image recommendation that's latest?

Sorry if this has been posted before. Today I took the liberty and upgraded to 18.04.1 LTS via do-release-upgrade. I'm noticing that /var/log almost immediately fills up by the journal, no matter how many times I delete it (I know you're not supposed to delete the filesystem journal) Reaching 100% usage on /var/log causes a multitude of problematic behaviors (i.e. apt-get breaks) user@TinkerBoard:/var/log$ df -h Filesystem Size Used Avail Use% Mounted on udev 1000M 0 1000M 0% /dev tmpfs 201M 16M 186M 8% /run /dev/mmcblk0p1 29G 6.4G 23G 23% / tmpfs 1004M 0 1004M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1004M 0 1004M 0% /sys/fs/cgroup tmpfs 1004M 4.0K 1004M 1% /tmp /dev/zram0 49M 48M 0 100% /var/log tmpfs 201M 0 201M 0% /run/user/1000 user@TinkerBoard:/var/log$ du -hsc /var/log/journal 48M /var/log/journal 48M total Changing the SystemMaxFileSize value (i.e. to 30M) on /etc/systemd/journald.conf does not make the journaling system obey - it still fills up (even after a reboot).

That's very nice to hear! Good job everyone!

Has anything been changed, in regards to stability or voltage control, with the last couple of kernels? My board is being surprisingly stable, currently with an up time of 35+ days. *knocks on wood*

Thanks!

Are these kernels out of beta? I do a dist-upgrade and see nothing as of yet, still on 4.11.6

I've just finished writing my SHT31-D (I2C) Nagios plugin. As promised, it can be found here for anyone else interested.

Are there any instructions available? Any precautions, etc? Thanks. PS: In the meantime, can I somehow downclock the SoC a little bit? Would that help any?

My tinker board appears to have crashed again after 1.8 weeks of uptime. Power supply is the micro-USB "official" RPi one, and it's rated at 2.5A , the SD card appears to be fine. Symptoms: Only the red led was powered on, I had no green (I/O) or yellow led (heartbeat) activity. When removing the power cord and reinserting it, it would power-on for a couple of seconds and then it would power-off by itself. I left it powered-off for around 2 minutes and then powered it on and it's working ok so far. I checked my graphs and I see that over the course of the last 2 weeks, the CPU was sustaining temps between 61-65.5 °C. Right now I'm noticing a 74°C temperature spike, which is slowly coming down to the previously observed temperatures. (This graph displays the last 24h) I'm not sure why the CPU raises it's temperature if the system has crashed. I've also reviewed the syslog and kernel logs, but I cannot find anything that would point me to the cause of the crash. It also must've refused to start because it was overheated, but why does it always work fine for almost two weeks and then suddenly decides to die? I would appreciate any pointers to help me investigate. Using mainline kernel. root@Tuxbox:~# lsb_release -a && uname -r No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial 4.11.6-rockchip

Ah okay, thanks for clarifying - I'll wait then.