Jump to content

Carlos Hartmann

Members
  • Posts

    6
  • Joined

  • Last visited

Everything posted by Carlos Hartmann

  1. It seems like what I was trying to install wasn't the correct package. Following this tutorial it all worked fine: http://www.bernaerts-nicolas.fr/linux/75-debian/335-debian-wheezy-install-monitor-eaton-ups
  2. Hi! I'm trying to install NUT because I connected a UPS device. I'd like to get it working so that the server is shutdown safely when there is a power interruption and that I get an e-mail notifying me as soon as there is an interruption. Already after installing via sudo apt install nut nut-client nut-server I get the following warnings: Setting up nut-client (2.7.4-8) ... Job for nut-monitor.service failed because the service did not take the steps required by its unit configuration. See "systemctl status nut-monitor.service" and "journalctl -xe" for details. invoke-rc.d: initscript nut-client, action "restart" failed. ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 24ms ago Process: 24611 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS) Dec 11 16:33:11 helios64 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. And the output of systemctl status nut-monitor.service is: ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 5min ago Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. Dec 11 16:33:12 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:14 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:15 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat And I can't use stuf like nut-scanner so the packages aren't completely installed. Googling around just confused me because it's not even clear to me where the mistake is or how to fix it. Any help is appreciated, even if just in form of "go there and ask them".
  3. Reporting back after roughly 12 hours of letting it transcode video under the new setting. It has not crashed, which it most likely would have otherwise. It also solved my mini problem that the server got too loud when working. The noise now is acceptable. Am I assuming correctly that I could do the same but with a lower CPU speed if I wanted less noise and would be willing to accept lower performance? But yes, my problem seems solved, this is amazing. Thanks all! I will report back how the server did after a few days of working.
  4. Setup: Helios64 with Armbian 20.08.8 Buster with Linux 4.4.213-rk3399. Will change to Linux 5.8 soon though. 5 x 8 TB drives. Not using battery. I’ve had this issue ever since beginning to use my Helios. It first happened when I tried building a RAID with OpenMediaVault: It would crash and reboot while building. Sometimes after only 10 minutes, sometimes after 8+ hours of working. The same is true for video transcoding nowadays: it will sometimes crash after a little while, sometimes after a few consecutive hours of working, but it will never be able to work much longer than 12 hours on such a task. Copying large files from the internet has a similar risk of crashing it. Also, it will not save the crash in the logs. For some reason, the timeframe when it crashed was always gone from the logs. Nowadays it’s even worse: My logs only go until December 11th and even if I clear them on the OMV interface, after the next reboot, they are there again and it refuses to log anything new. While the server is performing a demanding task, most figures in the ssh screen will be red: System Load at around 170%, CPU temp at 70°C etc. CPU usage on the OMV interface will be around 97%. At first I thought it was normal but a friend of mine told me servers should absolutely never reboot on their own; that this is an indication something is not right. My impression from the above-described behavior is that somehow my machine isn’t able to limit the amount of CPU used. I expected the server to become slower under more CPU stress, but instead it seems to not regulate well at all and overwork itself. Or maybe some part of the software/hardware is faulty and will randomly cause a crash. As you may have noticed, I’m rather new to a lot of things here. I have no idea how to even begin troubleshooting this so I’ll need some pointers from you. What could be the cause for this and what tests can I do to narrow it down?
  5. I'm getting a blank terminal window when running the command to connect to the console: $ screen /dev/tty.usbserial-XXXXXXXX 1500000 -L Of course I did input the correct usbserial number that shows up in the /dev/ directory. The very first time the terminal window displayed a lot of noise with seemingly random characters. I killed the window and re-opened, and now whenever I re-open it, the terminal window is just empty. I've restarted the helios twice already while connected in the terminal, but still nothing. Not sure where the error could be. EDIT: Forgot to say: I'm on Mac Catalina (OS 10.15), zsh-terminal. I do not own another machine currently, could set up a VM if the problem cannot be solved currently. The initial bunch of symbols is as follows: `�`���x�f������������`���������x�怘����怘�������f����怘��������怘����������怘���`������怘���f������怘����������怘���������~�� 怘����`�����~��怘����������怘����������怘����`�������怘����f������怘�������f����怘��������怘����������怘���`������怘���f������怘����������怘���������~��怘����`�����~��怘����������怘����������
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines