JhnW / ArgonOne-Native-Fan-Controller

Written in Rust fan control daemon for Argon One v2 case for Raspberry Pi 4B
MIT License
20 stars 3 forks source link

/usr/bin/argon_fan_controller: No such file or directory #1

Closed neutmute closed 11 months ago

neutmute commented 11 months ago

Hey there - The original argon scripts were unreliable for me - spinning the fan when it shoudn't have been (according to my config). I tried yours but get some odd behaviour

openhabian@openhab2:~/argon-one $ ./deploy.sh
openhabian@openhab2:~/argon-one $ /usr/bin/argon_fan_controller
-bash: /usr/bin/argon_fan_controller: No such file or directory

sudo systemctl restart argon_fan_controller journalctl -u argon_fan_controller

Jul 30 20:12:57 openhab2 systemd[1]: Started Argon One Fan Open Source Controller Service.
Jul 30 20:12:57 openhab2 systemd[29231]: argon_fan_controller.service: Failed at step EXEC spawning /usr/bin/argon_fan_controller: No such file or directory
Jul 30 20:12:57 openhab2 systemd[1]: argon_fan_controller.service: Main process exited, code=exited, status=203/EXEC
Jul 30 20:12:57 openhab2 systemd[1]: argon_fan_controller.service: Failed with result 'exit-code'.
Jul 30 20:12:57 openhab2 systemd[1]: argon_fan_controller.service: Scheduled restart job, restart counter is at 5.
Jul 30 20:12:57 openhab2 systemd[1]: Stopped Argon One Fan Open Source Controller Service.
Jul 30 20:12:57 openhab2 systemd[1]: argon_fan_controller.service: Start request repeated too quickly.
Jul 30 20:12:57 openhab2 systemd[1]: argon_fan_controller.service: Failed with result 'exit-code'.
Jul 30 20:12:57 openhab2 systemd[1]: Failed to start Argon One Fan Open Source Controller Service.

ls -l /usr/bin/argon_fan_controller

-rwxr-xr-x 1 root root 424216 Jul 30 17:40 /usr/bin/argon_fan_controller

ie: The file is there but if I try and execute it - it can't be found? It's a Raspberry Pi 4 running Openhabian.

Any ideas? πŸ€” I'm using the binary downloaded from releases

cat /etc/os-release

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

lscpu

Architecture:                    aarch64
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     1800.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
L1d cache:                       128 KiB
L1i cache:                       192 KiB
L2 cache:                        1 MiB
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm crc32 cpuid
JhnW commented 11 months ago

Hello. Try setting the file permissions (chmod) of the file to allow it to be extracted. 777 for the purposes of tests is fine, Now you can try run program "by finger" just invoke binary from /usr/bin (or just from unzipped archive).

If that doesn't work then I have some guesses about the distro you're using (glibc version) but I'll wait for more data.

neutmute commented 11 months ago

fast reply! Do you mean file permissions on the zip? I unzipped it fine and it deployed ok but the file seems to be invisible when I run it. /usr/bin/argon_fan_controller had +x on it as shown above

But I tried 777 anyway...

Before: stat --format '%a' /usr/bin/argon_fan_controller => 755

sudo chmod 777 /usr/bin/argon_fan_controller

After:

openhabian@openhab2:~ $ /usr/bin/argon_fan_controller
-bash: /usr/bin/argon_fan_controller: No such file or directory
openhabian@openhab2:~ $ ls -l /usr/bin/argon_fan_controller
-rwxrwxrwx 1 root root 424216 Jul 30 17:40 /usr/bin/argon_fan_controller
JhnW commented 11 months ago

I mean /usr/bin/argon_fan_controlle. But ok, I see its ok. Are you using 64-bits OS? I providing binary files only for aarch64.

Please check:

ldd /usr/bin/argon_fan_controller

neutmute commented 11 months ago
openhabian@openhab2:~ $ ldd /usr/bin/argon_fan_controller
        not a dynamic executable
openhabian@openhab2:~ $ uname -a
Linux openhab2 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

I thought I would install cargo/rust and try compiling my own binary but then

openhabian@openhab2:~ $ ls /home/openhabian/.cargo/bin
cargo  cargo-clippy  cargo-fmt  cargo-miri  clippy-driver  rls  rust-analyzer  rustc  rustdoc  rustfmt  rust-gdb  rust-gdbgui  rust-lldb  rustup
openhabian@openhab2:~ $ ./home/openhabian/.cargo/bin/cargo
-bash: ./home/openhabian/.cargo/bin/cargo: No such file or directory
openhabian@openhab2:~ $ ldd ./home/openhabian/.cargo/bin/cargo
ldd: ./home/openhabian/.cargo/bin/cargo: No such file or directory

πŸ€·β€β™‚οΈ I am not sure what I am doing wrong - this is making me feel like a linux noob πŸ˜…

JhnW commented 11 months ago

Unfortunately, this is the problem with distributing binary applications for Linux family systems (I also provide sources for them BTW, you can always compile the program on the target device, then it should always work). OpenSource on Linux is often a must.

Cargo installation etc. will give you nothing. Cargo is only used during build, it's not pip for python cvzy npm for Node to fetch dependencies dynamically.

I have idea. You have 64-bit ARM (as RPI4 be, aarch64) but you are using 32-bit OS (all major RPI OS are 32-bit, bot somme have 64-bit versions). I'm not sure why RPI community have problem with migrate to 64-bit OS but its fact.

Solution: use 64 bit OS (i think it ca be better choice for future, deplorably your distro provide 64-bit version too) or just compile controller yourself for target platform.

neutmute commented 11 months ago

ok will try - thanks for pointers πŸ‘