Jump to content

OpiOne: /dev/zram0 = /var/log full while apt update


guidol

Recommended Posts

Armbianmonitor:

while updating my dev-OPiOne

Welcome to Armbian bullseye with Linux 5.5.8-sunxi

package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb   [20.05.0-trunk]
firmware          [20.05.0-trunk] config[20.05.0-trunk] branch[dev]

Linux opi-one 5.5.8-sunxi #trunk SMP Wed Mar 18 21:19:37 +03 2020 armv7l GNU/Linux

via apt update I did get the follwing error-message:

Trigger für mime-support (3.64) werden verarbeitet ...
E: Schreibfehler - ~LZMAFILE (28: Auf dem Gerät ist kein Speicherplatz mehr verfügbar)

I did found out via df that /dev/zram0 = /var/log is used up to 100% :(

root@opi-one(192.168.6.114):~# df
Dateisystem            1K-Blöcke Benutzt Verfügbar Verw Eingehängt auf
/dev/zram0                 49584   48560         0  100% /var/log

but only zram0 seems to be full and not the complete memory:

MiB Mem :    491,5 total,    124,5 free,    101,3 used,    265,8 buff/cache
MiB Swap:    245,8 total,    242,8 free,      3,0 used.    360,8 avail Mem

After a reboot there is also 64% of the /dev/zram0 used and I dont know why :(
 

root@opi-one(192.168.6.114):~# df
Dateisystem            1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/zram0                 49584   28996     17004   64% /var/log

 

Spoiler

root@opi-one(192.168.6.114):/var/log# ls -l
insgesamt 264
-rw-r--r-- 1 root     root                0 Apr  4 19:06 alternatives.log
drwxr-xr-x 2 root     root             4096 Apr  4 19:09 apt
-rw-r--r-- 1 root     root            36237 Apr  4 19:14 armbian-hardware-monitor.log
-rw-r----- 1 root     adm              2188 Apr  4 19:17 auth.log
-rw-r--r-- 1 root     root                0 Apr  4 19:00 bootstrap.log
-rw-rw---- 1 root     utmp                0 Apr  4 19:00 btmp
drwxr-xr-x 2 _chrony  _chrony          4096 Okt 26 09:47 chrony
-rw-r----- 1 root     adm             20547 Apr  4 19:15 daemon.log
-rw-r----- 1 root     adm               607 Apr  4 19:14 debug
-rw-r--r-- 1 root     root                0 Apr  4 19:09 dpkg.log
-rw-r--r-- 1 root     root                0 Apr  4 19:00 faillog
drwxr-sr-x 3 root     systemd-journal  4096 Feb 25 19:02 journal
-rw-r----- 1 root     adm             35489 Apr  4 19:14 kern.log
-rw-rw-r-- 1 root     utmp              292 Apr  4 19:15 lastlog
drwxr-x--- 2 www-data www-data         4096 Mär 18 21:28 lighttpd
drwx------ 2 root     root            16384 Apr  4 19:14 lost+found
-rw-r----- 1 root     adm             34597 Apr  4 19:14 messages
drwxr-xr-x 2 pihole   pihole           4096 Feb 14 14:53 pihole
-rw-r--r-- 1 pihole   pihole           4052 Apr  4 19:14 pihole-FTL.log
-rw-r--r-- 1 pihole   pihole            706 Apr  4 19:14 pihole.log
-rw-r--r-- 1 root     root                0 Apr  4 19:00 pihole_updateGravity.log
drwx------ 2 root     root             4096 Dez 31 13:35 private
drwxr-xr-x 3 root     root             4096 Mär 18 21:28 runit
-rw-r----- 1 root     adm             57029 Apr  4 19:17 syslog
drwxr-xr-x 2 root     root             4096 Nov  2 13:55 sysstat
drwxr-x--- 2 root     adm              4096 Mär 18 21:28 unattended-upgrades
-rw-rw-r-- 1 root     utmp             2688 Apr  4 19:15 wtmp

 

Is there any chance to gain some space in /dev/zram0 or to configure a little bigger /dev/zram0?
(to use a part of the 265Mb remaining cache/buffer-ram)

 

The complete update to newer packages/kernel seems also to work with the full /dev/zram = /var/log:

Welcome to Armbian bullseye with Linux 5.5.15-sunxi

package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb   [20.05.0-trunk]
firmware          [20.05.0-trunk] config[20.05.0-trunk] branch[dev]

Linux opi-one 5.5.15-sunxi #trunk SMP Sat Apr 4 17:39:03 +03 2020 armv7l GNU/Linux

 

 

 

Link to comment
Share on other sites

Now I have 90% in /var/log after a reboot :(

df
Dateisystem            1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/zram0                 49584   41296      4704   90% /var/log

zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lzo         245,8M    4K   78B   12K       4 [SWAP]
/dev/zram0 zstd           50M 40,4M    1M  1,5M       4 /var/log

root@opi-one(192.168.6.114):/var/log/journal/14bb32cb9a1c40b29c1696d4acec6931# ls -l
insgesamt 40976
-rw-r----- 1 root systemd-journal 16777216 Apr  4 19:14 system@0005a27952ce7c96-f8789ed6a81b97f9.journal~
-rw-r----- 1 root systemd-journal  8388608 Apr  4 22:45 system@0005a27c483373ab-1b9f47dd2956de8e.journal~
-rw-r----- 1 root systemd-journal  8388608 Apr  4 22:56 system@0005a27c6cce90a5-1036e2f49bee28e6.journal~
-rw-r----- 1 root systemd-journal  8388608 Apr  4 23:18 system.journal

but I can't read the content of the system.journal-files :(
[EDIT] here are instructions for reading journal files:
https://www.linux-magazin.de/ausgaben/2016/02/systemd-journal/2/

If I delete these
files - they will be "restored" at the next boot :(

Link to comment
Share on other sites

9 minutes ago, Igor said:

I was fixed - how are your values in /etc/systemd/journald.conf

https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05

There I only have the default-file-entrys:
 

Spoiler

[Journal]
#Storage=auto
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg

 

I did now edit my /usr/lib/armbian/armbian-zram-config and inserted the lines from the fix at the right place (which were missing).
The fix inserted/corrected the SystemMaxUse=20M in /etc/systemd/journald.conf

 

Before a reboot I did enter a "journalctl --vacuum-size=5M"

 

And after the reboot I have:

root@opi-one(192.168.6.114):~# df
Dateisystem            1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/zram0                 49584   19676     26324   43% /var/log

Many thanks at @Igor ;)
 

 

Link to comment
Share on other sites

On 4/4/2020 at 11:35 PM, Igor said:

I was fixed - how are your values in /etc/systemd/journald.conf

https://github.com/armbian/build/commit/2f389a6cb6944983bbbaba15ef2b3cba228e9a05

@Igor I have two bullseye testing sbcs which seem to ignore the setting
SystemMaxUse=20M in /etc/systemd/journald.conf

var/log get full to 100% only on these bullseye sbcs but not on the buster sbcs

 

both show 
System diagnosis information will now be uploaded to gzip: /var/log/armbian-hardware-monitor.log.1.gz:
No such file or directory

while armbianmonitor -u (OK, I did a journalctl --vacuum-size=5M shortly  ago)

 

NPi Neo2 with bullseye:
http://ix.io/2lY7
NanoPi K1 Plus with bullseye:
http://ix.io/2lY8

Maybe there is to less output from armbianmonitor because of the vacuum?

Link to comment
Share on other sites

This looks strange for me (here the "red" ones)  - a short part from journalctl -b
but sometimes there are messages which arent red:

 

May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20>
May 14 11:56:14 npi-neo2-24 rsyslogd[758]: action 'action-1-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog>
May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20>
May 14 11:56:14 npi-neo2-24 rsyslogd[758]: action 'action-1-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2002.0 try https://www.rsyslog>
May 14 11:56:14 npi-neo2-24 rsyslogd[758]: file '/var/log/syslog'[7] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2002.0 try https://www.rsyslog.com/e/20>

 

here are some "normal green" ones from the journal:

May 14 11:45:06 npi-neo2-24 CRON[416455]: pam_unix(cron:session): session closed for user root
May 14 11:55:01 npi-neo2-24 CRON[428664]: pam_unix(cron:session): session opened for user root by (uid=0)
May 14 11:55:01 npi-neo2-24 CRON[428665]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

 

Link to comment
Share on other sites

1 hour ago, guidol said:

I have two bullseye testing sbcs which seem to ignore the setting


Good to know, thanks. ... I also noticed some other problems related to haveged, which requires apparmor and when that is enabled it still doesn't work. Perhaps Bullseye is too fragile atm and since it will remain unsupported (at this release), this is low priority to fix atm

Link to comment
Share on other sites

2 hours ago, Igor said:


Good to know, thanks. ... I also noticed some other problems related to haveged, which requires apparmor and when that is enabled it still doesn't work. 

I will have an (bulls)eye on it - because I had the kernel freezed to 5.6.8 and defreezed it today.

Now - after the update - I have 5.6.12 and since 2 hours /var/lag % hasnt grown.
Maybe ist has been solved in 5.6.12 or the newer packages since 5.6.8

Link to comment
Share on other sites

27 minutes ago, guidol said:

Maybe ist has been solved in 5.6.12 or the newer packages since 5.6.8


Anything is possible when using bleeding edge stuff ;) 

Link to comment
Share on other sites

Dear all,

I gave the new opi0 bullseye image a try, since It seems to be supported now. It may be worth to have a fresh look at the limits for systemd journald logging, and log rotation. My /var/log was loaded upto 45M some hours after booting, installing packages on the opi0, mainly due to /var/log/journal. I vacuumed it to 10M but after some reboots, package installations and hours it was full again although SystemMaxUse=20M by default.
 

Additionally, the log rotation (fired every 15 minutes from /etc/cron.d/armbian-truncate-logs) does not seem to work properly due to an issue in the script that is started with /bin/sh (see script line 1, instead of a shell that performs the $() command expansion):

% sudo /usr/lib/armbian/armbian-truncate-logs

[sudo] password for dennis: 
/usr/lib/armbian/armbian-truncate-logs: 18: /etc/default/armbian-ramlog: Syntax error: "(" unexpected

 

Running it with bash seems to work fine (sudo bash /usr/lib/armbian/armbian-truncate-logs, which also vacuums the journal).

 

After deciphering the journald.conf manpage, I found that both runtime /run/log/journal, as persistent /var/log/journal are running, and /var/log/journal is not really persistent since it is actually mapped zram memory (journald does not care and treats it as disk).

 

% egrep -i "(system|runtime)MaxUse" /etc/systemd/journald.conf
SystemMaxUse=20M
#RuntimeMaxUse=
 

% sudo journalctl --vacuum-size=10M
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb79ce3b8f57-f277d6397cc77cac.journal~ (380.0K).
Deleted empty archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~ (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~ (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb77ab234dfb-97d2013e1117189a.journal~ (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~ (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/system@0005cb787689a85a-c5fb08a0411e45bd.journal~ (2.5M).
Deleted archived journal /var/log/journal/078479a1b0a4459f80590dd571c3d6de/user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~ (2.5M).
Vacuuming done, freed 30.4M of archived journals from /var/log/journal/078479a1b0a4459f80590dd571c3d6de.
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal/078479a1b0a4459f80590dd571c3d6de.
 

% ls -lsa /run/log/journal/078479a1b0a4459f80590dd571c3d6de
total 5056
  0 drwxr-s---+ 2 root systemd-journal    200 Sep  8 11:58 .
  0 drwxr-sr-x+ 3 root systemd-journal     60 Sep  8 11:01 ..
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:51 system@6b593560fcd344f2910e96f6d1a94416-000000000000719c-0005cb7a7b871b5f.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:52 system@6b593560fcd344f2910e96f6d1a94416-0000000000007493-0005cb7a81dbae26.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:54 system@6b593560fcd344f2910e96f6d1a94416-0000000000007783-0005cb7a85740dde.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:55 system@6b593560fcd344f2910e96f6d1a94416-0000000000007a7a-0005cb7a8c94d731.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:56 system@6b593560fcd344f2910e96f6d1a94416-0000000000007d6f-0005cb7a8d656445.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:57 system@6b593560fcd344f2910e96f6d1a94416-0000000000008062-0005cb7a93bd9e11.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 11:58 system@6b593560fcd344f2910e96f6d1a94416-0000000000008352-0005cb7a9754eac1.journal
632 -rw-r-----+ 1 root systemd-journal 647168 Sep  8 12:32 system.journal
 

% ls -lsa /var/log/journal/078479a1b0a4459f80590dd571c3d6de
total 12740
   4 drwxr-sr-x  2 root systemd-journal    4096 Sep  8 11:58 .
   4 drwxr-sr-x  3 root systemd-journal    4096 Aug 26 10:39 ..
2564 -rw-r-----  1 root systemd-journal 2621440 Sep  8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~
2564 -rw-r-----  1 root systemd-journal 2621440 Sep  8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal
2476 -rw-r-----+ 1 root systemd-journal 2527232 Sep  8 11:01 system.journal
2564 -rw-r-----  1 root systemd-journal 2621440 Sep  8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal
2564 -rw-r-----  1 root systemd-journal 2621440 Sep  8 09:36 user-1000.journal

 

% ls -lsa /var/log.hdd/journal/078479a1b0a4459f80590dd571c3d6de
total 43904
   4 drwxr-sr-x 2 root systemd-journal    4096 Sep  8 09:56 .
   4 drwxr-sr-x 3 root systemd-journal    4096 Aug 26 10:39 ..
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 07:46 system@0005cb77143d39ed-a0190e6a8b8f96ef.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:28 system@0005cb77ab234dfb-97d2013e1117189a.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:25 system@0005cb787689a85a-c5fb08a0411e45bd.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:37 system@0005cb78a256a261-d8ca0603791c37d6.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:28 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000001-0005cb77ab1c0c05.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:53 system@0368477b592e43fdbf9ffcfb6934d264-00000000000002be-0005cb77ab27dc7d.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:18 system@0368477b592e43fdbf9ffcfb6934d264-0000000000000960-0005cb7805815938.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 07:46 system@1c1a53e8b25d40f3b676b26240347188-0000000000000001-0005ca73fa192ab2.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:26 system@1e380884930f4d539d6a0d93d2b03d39-0000000000000001-0005cb7876859703.journal
 376 -rw-r----- 1 root systemd-journal  385024 Sep  8 09:37 system.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:10 user-1000@0005cb7769ae3241-2385d20dac4738ae.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:28 user-1000@0005cb77ab294eee-86b91930cb2eb4a9.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:25 user-1000@0005cb787781d2a7-d60e1ce6a19e246b.journal~
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 07:46 user-1000@7268c35dcad84410bca267900c47dcf3-00000000000003de-0005cb76b53d43a7.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:26 user-1000@933777cd01ac4494a761849c2e955801-00000000000002ee-0005cb787781bf5f.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 08:43 user-1000@bd369698bf69432a8bc7ab495a90d103-00000000000002cd-0005cb77abdedbd0.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:18 user-1000@bd369698bf69432a8bc7ab495a90d103-0000000000000a2b-0005cb7811371fa6.journal
2560 -rw-r----- 1 root systemd-journal 2621440 Sep  8 09:36 user-1000.journal
 

% sudo journalctl --disk-usage
Archived and active journals take up 17.3M in the file system.
 

Kind regards,

Dennis

Link to comment
Share on other sites

Hi again,
Just updated and rebooted bullseye on nanopi neo3 and now the journals take 50M, before the reboot it was 17.3M ....     Fortunately, the log rotation seems to be working again has /bin/bash on first line now, so after 15 minutes /var/log was back to reasonable size.                                                                          

Could not yet reproduce this on opi0, it used 20M of journals after reboot.


Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.63-rockchip64                                                                       
                                                                                                                                        
System load:   100%             Up time:       0 min                                                                                    
Memory usage:  12% of 978M      IP:            192.168.0.13                                                                             
CPU temp:      60�°C            Usage of /:    29% of 15G                                                                               
# journalctl --disk-usage                                                                                               
Archived and active journals take up 50.6M in the file system.
npin3bullseye:~:% df -h /var/log                                                                                                        
Filesystem      Size  Used Avail Use% Mounted on                                                                                        
/dev/zram1       49M   48M     0 100% /var/log

 

Welcome to Armbian 21.08.2 Bullseye with Linux 5.10.60-sunxi 

                                                                                                                                        
System load:   48%              Up time:       0 min                                                                                    
Memory usage:  15% of 491M      IP:            192.168.0.30                                                                             
CPU temp:      57�°C            Usage of /:    21% of 15G                                                                               
                                                                                                                                        
[ General system configuration (beta): armbian-config ]                                                                                 
% journalctl --disk-usage                            

Archived and active journals take up 20.0M in the file system.                                                                          
opi0bullseye:~:% df -h /var/log                                                                                                         
Filesystem      Size  Used Avail Use% Mounted on                                                                                        
/dev/zram1       49M   27M   19M  60% /var/log 


Kind regards,

Dennis

Link to comment
Share on other sites

Hi Again,

The problem seems to be /var/log.hdd/journal which is copied back to /var/log/journal after reboot without cleaning.

 

Directly after a reboot:

% du /var/log/journal /var/log.hdd/journal
46560   /var/log/journal/50bea5a2341c40588d32c8103dea6e71
46568   /var/log/journal
46320   /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71
46324   /var/log.hdd/journal


% sudo diff -r /var/log/journal /var/log.hdd/journal
[sudo] password for dennis: 
Only in /var/log/journal/50bea5a2341c40588d32c8103dea6e71: system@0005cc0672bea9a2-be31a0e4284cf010.journal~
Binary files /var/log/journal/50bea5a2341c40588d32c8103dea6e71/system.journal and /var/log.hdd/journal/50bea5a2341c40588d32c8103dea6e71/system.journal differ
 

Kind regards,

Dennis

Link to comment
Share on other sites

On 9/9/2021 at 8:48 AM, Dennboy said:

Additionally, the log rotation (fired every 15 minutes from /etc/cron.d/armbian-truncate-logs) does not seem to work properly due to an issue in the script that is started with /bin/sh (see script line 1, instead of a shell that performs the $() command expansion):

 

https://github.com/armbian/build/pull/3115

This should / will be fixed with an update when it will be issued. When there will be time for that. Try with self build image.

 

On 9/9/2021 at 8:48 AM, Dennboy said:

I gave the new opi0 bullseye image a try, since It seems to be supported now.


Debian officially release Bullseye just two weeks prior to our release so it was a hard decision. We are expecting problems to happen, but there is little to be done, especially if bugs are coming somewhere from Debian packages, we don't maintain. Or changes in Debian changed our features into bugs. Hard to tell without research.

Link to comment
Share on other sites

Hi Igor,
Thanks for your support! Bullseye already feels stable enough for my purposes (synchronized voltage/current sensors for green R&D projects).

 

I temporarily fixed my /var/log/journal size issue at (every) boot by clearing /var/log.hdd/journal and copying over /var/log/journal after logrotate has run. Guess this could be automated somehow in the boot scripts.


Kind regards,

Dennis

Link to comment
Share on other sites

On 5/14/2020 at 5:14 PM, guidol said:

@Igor I have two bullseye testing sbcs which seem to ignore the setting
SystemMaxUse=20M in /etc/systemd/journald.conf

var/log get full to 100% only on these bullseye sbcs but not on the buster sbcs

 

 

Thanks for this.

Confirmed the same bug can also be found on Bulleseye image for Allwinner H6 TX box:

Armbian_21.11.0-trunk_Aw-h6-tv_bullseye_current_5.10.62.img.xz ]  by balbes150

 

ZRAM log was getting full again after device reboot & also due to Bulleseye image

    "ignore the setting SystemMaxUse=20M in /etc/systemd/journald.conf"

 

For now I'll fallback to Buster image previously downloaded for the device.

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines