+- Hilscher Community Forum (https://forum.hilscher.com)
+-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html)
+--- Forum: Software (https://forum.hilscher.com/forum-5.html)
+--- Thread: Remote Access (/thread-321.html)
Pages:
1
2
Remote Access - Jonas.Sellmann@outlook.de - September-19th-2018
Hello,
in an other thread I already asked, if it's possible to restart the netPi from remote (Resart/Access NetPi from Remote).
Now the same thing happened with an other netPi. Is there still no chance to restart the netPi from remote access?
Thanks in advance,
JonasÂ
RE: Remote Access - Armin@netPI - September-19th-2018
Hello Jonas,
so do you get the same output "502 Bad Gateway" as well with this netPI? Did you update this netPI to the latest software version too, like the other one?
Still if the landing page cannot be reached any more as front end you have not chance to use the "System/reset" function.
Do you have a time interval after this problem happened now?
In netPIs control panel you get an overview of the ressources available in term of CPU usage, memory usage etc. Maybe you logged onto this netPI some days before and were able to have a look at it. Was it indicating unusal data?
RE: Remote Access - Jonas.Sellmann@outlook.de - September-19th-2018
(September-19th-2018, 06:58 AM)Armin@netPI Wrote: Hello Jonas,
so do you get the same output "502 Bad Gateway" as well with this netPI? Did you update this netPI to the latest software version too, like the other one?
Still if the landing page cannot be reached any more as front end you have not chance to use the "System/reset" function.
Do you have a time interval after this problem happened now?
In netPIs control panel you get an overview of the ressources available in term of CPU usage, memory usage etc. Maybe you logged onto this netPI some days before and were able to have a look at it. Was it indicating unusal data?
Hello Armin,
yes it's the same output "502 Bad Gateway". Yes, we updated the netPi with the system software 1.1.3.0.
Is there no coption to access the main linux system of the netPi?
It were only two to three weeks the netPi was working.
Yes, the cpu usage was most of the time between 30-50 % and sometimes at 80%. Memory usage was no problem, only at 30% and storage usage at 40%.
Description of our application:
We have three container running. One container is for openvpn connection. This connection is still working. So I can access the local network.
The other container is connected to four bluetooth devices and is receiving data from thenm, creates output to the console and writes the data to
the third container, which is a postgresql database.
I can still access the bluetooth container with ssh, but always I try to use a command either there comes up "input/output error" or there comes up "command not found".
We can't identify what we are doing wrong. I don't think that there is a problem with the write cycles of the sd card.
Do you have an idea?
Thanks in advance,
Jonas
RE: Remote Access - Armin@netPI - September-19th-2018
Jonas, I don't know if you would provide too much internal and intellectual information ... but is it possible that we can get the three containers to us? So then we can start an evaluation of all three containers here and make a long term test. Or do those containers need a special external hardware to run?
RE: Remote Access - Armin@netPI - September-19th-2018
Quote:I can still access the bluetooth container with ssh, but always I try to use a command either there comes up "input/output error" or there comes up "command not found".
I just want to understand the three containes a little closer. We share the opinion that in no way any container ever should cause netPI to stop normal operation respectively cause "bad gateway" for its web interface.
So you log in to your netPI via openVPN container ... and over this connection you can reach the bluetooth container via ssh and open a terminal. Is my understanding correct?
And then if you call in this terminal a standard linix console command like "dir" or "ls" or "apt-get" or anything else you get the "input/output error" or command not found, right?
RE: Remote Access - Armin@netPI - September-19th-2018
What is if your try to access netPI with https://<ip address netpi>/portainer? Does it work?
RE: Remote Access - Jonas.Sellmann@outlook.de - September-19th-2018
(September-19th-2018, 09:28 AM)Armin@netPI Wrote: Jonas, I don't know if you would provide too much internal and intellectual information ... but is it possible that we can get the three containers to us? So then we can start an evaluation of all three containers here and make a long term test. Or do those containers need a special external hardware to run?
No, unfortunately we can't do that. Moreover for the communication, the container need speacial bluetooth devices, we are developing.
(September-19th-2018, 09:45 AM)Armin@netPI Wrote:Quote:I can still access the bluetooth container with ssh, but always I try to use a command either there comes up "input/output error" or there comes up "command not found".
I just want to understand the three containes a little closer. We share the opinion that in no way any container ever should cause netPI to stop normal operation respectively cause "bad gateway" for its web interface.
So you log in to your netPI via openVPN container ... and over this connection you can reach the bluetooth container via ssh and open a terminal. Is my understanding correct?
And then if you call in this terminal a standard linix console command like "dir" or "ls" or "apt-get" or anything else you get the "input/output error" or command not found, right?
Yes, thats exactly what I'm doing. Yes standard linux commands does not work.
(September-19th-2018, 09:56 AM)Armin@netPI Wrote: What is if your try to access netPI with https://<ip address netpi>/portainer? Does it work?
Unfortunately i tried this description to restart the netPi with the terminal of the conatiner: https://matoski.com/article/emergency-reboot-shutdown-linux-sysrq/
The netPi was shut down, but does not restart and isn't accessible anymore.
Tomorrow we have a chance get access to the hardware, so maybe we can fix the errors.
But in the future we need a system that we can manage from remote, when there are errors, because we don't always have the chance to go to our customers.
Isn't there a chance to get access to the linux system of the host system?
RE: Remote Access - Armin@netPI - September-19th-2018
Wow Jonas, I tried calling the two commands since I was curious
$ echo 1 > /proc/sys/kernel/sysrq
$ echo b > /proc/sysrq-trigger
one after the other and indeed my netPI here started to reboot and I also can tell you that my netPI restarted correctly.
I followed the HDMI output and log trace and the whole netPI system was coming back as it was before.
Of course I don't know what these commands are really doing and how reliable they are, but if they are always working fine I am wondering that your netPI got stuck after your called these two commands.
RE: Remote Access - Armin@netPI - September-19th-2018
Jonas, I just continued my tests with the reset command
I filled my netPI SD card by 100% writing a big file to it using the command
dd bs=1024 count=10000000 </dev/urandom >outputfile
Even though my netPI was still accessible accross the web interface.
Then I called the special reset command, netPI rebooted but wasn't able to start any container any more cause of missing disk space.
I know it is not your error scenario, but interesting to see that missing disk space causes Docker not to start any container any more.
Then you confirmed "no linux" command can be called any more in the bluetooth container. So not even the important "dmesg" command that lists you important log entries can't be called any more? I know you can't tell it today since your netPI is down ... but maybe in future.
Thx
RE: Remote Access - Jonas.Sellmann@outlook.de - September-19th-2018
(September-19th-2018, 11:07 AM)Armin@netPI Wrote: Jonas, I just continued my tests with the reset command
I filled my netPI SD card by 100% writing a big file to it using the command
dd bs=1024 count=10000000 </dev/urandom >outputfile
Even though my netPI was still accessible accross the web interface.
Then I called the special reset command, netPI rebooted but wasn't able to start any container any more cause of missing disk space.
I know it is not your error scenario, but interesting to see that missing disk space causes Docker not to start any container any more.
Then you confirmed "no linux" command can be called any more in the bluetooth container. So not even the important "dmesg" command that lists you important log entries can't be called any more? I know you can't tell it today since your netPI is down ... but maybe in future.
Thx
Ok, in the future I will test the command 'dmesg'. For example the command 'echo' I could use.
Do you have any other ideas how we can avoid these error in the future?
Thanks,
Jonas