barish

Due to systemd, Journal is going to replace all journals sooner or later, it's already one of the busiest journaling on the sytem. The logs are binary and can't be rotated like text logs, they are already compressed and can't be read by text editor, instead only by journalctl. Thus, in /usr/lib/armbian/armbian-ramlog , the directory /var/log/journal is excluded from standard log rotation and copying to HDD. Instead, it is copied once to /var/log.hdd/journal and a soft-link is created: /var/log/journal pointing to -> /var/log.hdd/journal . The RAM logging was introduced to spare the SD card, preventing many write actions that wear the SD card quickly. But this really busy log, including all system messages, is now written directly to the SD card. If this is the only way of preserving older systemd logs, shouldn't we then at least reconfigure journald in a way to e.g. log into RAM /run/log/journal and only snyc to SD card every n hours? Or maybe we could reduce the log level of journald (which is by default "debug") to e.g. "err" and reduce the write activity in that way? For me, it appears right now, that all the benefits of logging to RAM disk are canceled out by having journald log to SD card? Please correct me if I am mistaken in any of my assumptions above.

I find it hard to imagine that maybe bash scripts interfere with each other and bash variables get confused across shell borders!?! It’s up to now the only guess I can come up with. This is maybe related to the early boot process where not everything is aligned yet? This is all wild guessing, I haven’t found a way to further analyze, because even auditd is failing on the armbian image I am using.

I haven't found the cause, but I deactivated armbian-hardware-optimize.service, and did about 70 reboots afterwards, without any file corruption taking place. So I hope that armbian-hardware-optimization.sh (which is called by the above service) is involved in the error and its deactivation prevents any further file corruption.

Thanks @Werner, as I understand it, audit is a component of SELinux, but can be activated standalone, too. I don't know how to troubleshoot this, all output (systemctl status auditd) is identical to a working auditd on other board, just the log file stays empty. For the record, I am running Armbian 21.02.3 Espressobin Debian buster current, kernel is 5.10.21-mvebu64 .

In my case, /boot/armbianEnv.txt looks like this (but I have had variations, of this, too): /var/log/alternatives.log { monthly rotate 12 compress delaycompress missingok notifempty create 644 root root } usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u Then, in /etc/logrotate.d, two files seem to be corrupt: 1. alternatives, 2. armbian-hardware-monitor, which had the complete contents of armbianEnv.txt. I run nginx, sambad, forked-daapd, nextcloud, mini-dlna and dnsmasq. No apache though. Edit: /etc/logrotate.conf is also truncated, thus corrupted. Hadn't noticed before, thanks @schwar3kat.

This is about three Helios, one Pine64 and two EspressoBin boards. @Werner could we move this thread to a place visible to others than Rockchip please?

Found this in /var/log/kern.log : Jun 28 09:14:51 localhost kernel: [ 0.026499] audit: initializing netlink subsys (disabled) Jun 28 09:14:51 localhost kernel: [ 0.026793] audit: type=2000 audit(0.024:1): state=initialized audit_enabled=0 res=1 And I tried auditd on another board of mine (Olinuxino micro) also running Buster, where it is working fine. So either it is a board topic or it's a stupid user topic... 😕

I am not shure if this is board specific so I post it here and hope that you might be willing to try this on your board: - I installed audit: apt install auditd - I set up a rule for a file audit should watch: auditctl -w /boot/armbianEnv.txt -p wa - I change or touch the file being watched: touch /boot/armbianEnv.txt - I have a look at the log of audit: cat /var/log/audit/audit.log And then ––– I see nothing... Any hints what's going wrong? My guess is that the kernel might be lacking the audit module?!

Unfortunately, auditd is not working at all. It just doesn't show any file access whatsoever, even though the demon is running and the rule is set. So this is of no help on my system. edit: Maybe the Armbian kernel is compiled without audit kernel module!?

Same has happened on EspressoBin running Buster 5.10. I don‘t believe it to be a filesystem problem. It looks like something happening at boot time perhaps while running /usr/lib/armbian-hardware-optimization.sh ? I will try to go further into it.