SomeArmbianForumUser

Members
  • Content Count

    22
  • Joined

  • Last visited

About SomeArmbianForumUser

  • Rank
    Member

Recent Profile Visitors

629 profile views
  1. For more aggressive log rotation, I have now changed /etc/logrotate.d/rsyslog like this: root@micro:~# diff /etc/logrotate.d/rsyslog{~,} -u --- /etc/logrotate.d/rsyslog~ 2017-01-18 23:14:38.000000000 +0100 +++ /etc/logrotate.d/rsyslog 2018-01-23 13:25:45.141409984 +0100 @@ -1,10 +1,9 @@ /var/log/syslog { - rotate 7 + rotate 4 daily missingok - notifempty - delaycompress + ifempty compress postrotate invoke-rc.d rsyslog rotate > /dev/null @@ -25,11 +24,10 @@ /var/log/messages { rotate 4 - weekly + daily missingok - notifempty + ifempty compress - delaycompress sharedscripts postrotate invoke-rc.d rsyslog rotate > /dev/null And created a new logrotate file for openhab2: root@micro:~# cat /etc/logrotate.d/openhab2 /var/log/openhab2/*.log { rotate 4 daily missingok ifempty compress postrotate service openhab2 restart endscript } Invoking these files with logrotate --force --verbose <filename> produces no error, and performs the expected operations. If this works out in the long run, I can probably reduce the ramlog size back to 50MB.
  2. I have now found root@micro:~# find / -name log2ram* /etc/default/log2ram Where I can increase the size of that file system. I can still not upload armbianmonitor - seems like the armbian server has trouble: root@micro:~# armbianmonitor -u System diagnosis information will now be uploaded to curl: (56) Recv failure: Connection reset by peer Please post the URL in the forum where you've been asked for. root@micro:~# armbianmonitor -u System diagnosis information will now be uploaded to <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>Please post the URL in the forum where you've been asked for. root@micro:~# armbianmonitor -u System diagnosis information will now be uploaded to <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>Please post the URL in the forum where you've been asked for. I would still like advice how to increase the logrotate aggressiveness - delete old logs earlier, so they do not take as much space in ramlog.
  3. Apparently, I can't: root@micro:~# armbianmonitor -u System diagnosis information will now be uploaded to /usr/bin/armbianmonitor: line 374: [: -gt: unary operator expected /usr/bin/armbianmonitor: line 374: [: -gt: unary operator expected /usr/bin/armbianmonitor: line 374: [: -gt: unary operator expected /usr/bin/armbianmonitor: line 374: [: -gt: unary operator expected <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>Please post the URL in the forum where you've been asked for. Interesting. In the meantime I had deleted the largest file in /var/log, but this is not reflected in the output of df for the log2ram filesystem. After the armbianmonitor error, I tried rebooting and manually unmounting /var/log in an attempt to maybe get armbianmonitor -u to work, but no success. My openhab2 continues to run just fine on that device.
  4. Thanks for Ramlog. I have installed Armbian_5.35_Micro_Debian_stretch_next_4.13.16 and not done anything in terms of Ramlog setup. What should I do when it is full? Or to avoid that it gets full? Symptoms: * Aptitude complained about "no space left on device" on exit. * df: root@micro:~# df -h Filesystem Size Used Avail Use% Mounted on udev 432M 0 432M 0% /dev tmpfs 100M 12M 89M 12% /run /dev/mmcblk0p1 29G 3.0G 26G 11% / tmpfs 499M 0 499M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 499M 0 499M 0% /sys/fs/cgroup tmpfs 499M 36K 499M 1% /tmp log2ram 50M 50M 0 100% /var/log tmpfs 100M 0 100M 0% /run/user/0 * usage: root@micro:~# du /var/log/* | sort -n 0 /var/log/armhwinfo.log 0 /var/log/debug 0 /var/log/influxdb 0 /var/log/ntpstats 0 /var/log/sysstat 0 /var/log/user.log 4 /var/log/btmp 4 /var/log/debug.1 4 /var/log/kern.log 4 /var/log/messages 8 /var/log/aptitude 8 /var/log/auth.log 8 /var/log/unattended-upgrades 24 /var/log/faillog 28 /var/log/wtmp 36 /var/log/user.log.1 44 /var/log/alternatives.log 48 /var/log/armhwinfo.log.1.gz 52 /var/log/syslog.3.gz 60 /var/log/bootstrap.log 136 /var/log/auth.log.1 140 /var/log/apt 160 /var/log/kern.log.1 192 /var/log/messages.1 248 /var/log/syslog.2.gz 288 /var/log/lastlog 348 /var/log/dpkg.log 3060 /var/log/daemon.log 3092 /var/log/syslog 10208 /var/log/openhab2 14912 /var/log/syslog.1 18084 /var/log/daemon.log.1 I know that openHAB2 is causing the majority of the log messages. That's the purpose of that computer. How can I increase the amount of RAM used for Ramlog, or make the log rotation more aggressive?
  5. Why are you messing with wpa_supplicant when you were already "able to connect to [your] wifi AP using nmtui, and now [you're] trying to share the internet with any device that is connected in eth0 ...". In the simplest realization this would just need a static private IP address for eth0, ip forwarding, a NAT iptables rule, static addresses, routes, and dns settings on the connected devices. You say you are tired from trying out so many things but you do not describe what went wrong in even a single try.
  6. Why choose the orange pi zero for this? It does not have bluetooth on board.
  7. That link says "an encrypted wireless network requires entropy". That's understood. No questions about that. You have suggested that also my unencrypted example network from post 13 requires entropy. Could you please explain why? Actually I see a rise in available entropy from the start of hostapd. That alone does not contradict your suggestion, as there might be an entropy valley during the start that I do not detect with my before and after measurements.
  8. I am surprised that an unencrypted, open wireless network (cf post #13) needs entropy. Why is that?
  9. You have made the same mistake graphically that I made physically at first. Sorry for not being clear enough. In that picture, you have actually encircled R353/R352. These are _not_ identical to R135/R136. R135/R136 sit directly below the encircled resistors in that picture. R353/R352 can stay, R135/R136 have to go. A correctly modified board looks like this (test if I can include images from the sunxi wiki): I have now corrected the wiki page. I could not replace the image with the wrong resistors highlighted, so I uploaded a new one with a different name and used this in the article to highlight the R135/R136 resistor positions:
  10. Success: My First OPZ runs on PoE. I have used this PoE Injector, extended it with this fuse holder, currently it contains a 200mA slow acting fuse. I'm using this 24V 0.5A power supply and these buck converters. I would not recommend the buck converters, because they are very tricky to adjust.
  11. To be fair, the HW manufacturer planned for direct 5V injection, which would only produce 166mW wasted heat through these resistors. Armbians suggested a more practical aproach with higher network voltage and a buck converter, for which I'm thankful.
  12. It seems that I'm the first person (*) to actually tinker with passive PoE on the Orange Pi Zero. I'm not finished yet, but I'd like to publish this warning for the benefit of anyone who follows on this path: Before you inject power over ethernet, remove resistors R135 and R136 from the Orange Pi Zero board! These resistors can be found on the top side of the board, next to the RJ45 jack: (Apparently I'm not allowed to post images. Be sure to remove the correct ones. the resistors nearest the label "R135/R136"l are actually R353/R352. R135/136 are nearer to the RJ45 connector. Yes I found out by removing the wrong ones first.) If these resistors are left on the board, they will connect POE+ and POE-GND with a resistance of 150Ω. At 24V, that would produce 3.8W of heat. These resistors would not sustain that. I found out something's wrong in the good old tradition of connecting power and see if smoke develops. Then I cut them off with small wire cutters (I suck at SMD soldering). (*) The image at http://linux-sunxi.org/images/c/c1/OPi_Zero_preparing_Access_Point.jpg also shows PoE preparations, but apparently it has not actually been used with PoE power, as you can see R135 still intact, and the part of R136 that can bee seen also shows no damage.
  13. What's the point? Once started, they are in RAM anyway.
  14. This looks like a bottleneck. Define "all". 16 bytes every half second will fill up 512 MB RAM in a approx. half a year. Not taking into account overhead, compression, other processes that use RAM. You should plan for a maximum measurement duration significantly lower than that. And check the performance of your DAQ system for the end of the planned measurement period, i.e. with a large set of simulated data already in memory.