Rpi4 Shuts Down Periodically

Hi all. I'm running Manjaro on an Rpi4 remotely -- it is several time zones away. I use it for a VPN, file sharing, and other useful remote capabilities. Recently, it has started to be inaccessible. I believe it is rebooting, but it is hard to tell from the journalctl entries, which appear to be deleted on each reboot.

I've pasted below the inxi output. I can post journalctl snippets if they will help and the Rpi4 is actually working, but the information is limited to what happened since the last reboot -- which means I can't seem to get info on the crash itself!

Hoping someone has an idea of what is going wrong, or at least how I can get more information on it.

inxi -Fxxxza --no-host:

System:    Kernel: 4.19.108-1-MANJARO-ARM aarch64 bits: 64 compiler: gcc v: 9.2.0 
           parameters: coherent_pool=1M 8250.nr_uarts=0 cma=64M cma=256M 
           video=HDMI-A-1:1920x1080M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0 
           smsc95xx.macaddr=DC:A6:32:30:C8:3D vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 root=/dev/mmcblk0p2 rw 
           rootwait console=ttyS0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N 
           dwc_otg.lpm_enable=0 kgdboc=ttyS0,115200 elevator=noop snd-bcm2835.enable_compat_alsa=0 
           Desktop: Gnome 3.36.0 wm: gnome-shell dm: GDM 3.34.1, LightDM 1.30.0 Distro: Manjaro ARM 
Machine:   Type: ARM Device System: Raspberry Pi 4 Model B Rev 1.1 details: BCM2835 rev: c03111 serial: <filter> 
CPU:       Topology: Quad Core model: N/A variant: cortex-a72 bits: 64 type: MCP arch: ARMv8 family: 8 model-id: N/A 
           stepping: 3 microcode: N/A 
           features: Use -f option to see features bogomips: 432 
           Speed: 600 MHz min/max: 600/1500 MHz Core speeds (MHz): 1: 600 2: 600 3: 600 4: 600 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 mitigation: __user pointer sanitization 
           Type: spectre_v2 status: Vulnerable 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: bcm2835-vc4 driver: vc4_drm v: N/A bus ID: N/A chip ID: brcm:soc 
           Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
           Display: server: X.Org 1.20.8 driver: modesetting unloaded: fbdev compositor: gnome-shell 
           resolution: 2560x1440~60Hz 
           OpenGL: renderer: llvmpipe (LLVM 9.0.1 128 bits) v: 3.3 Mesa 20.0.2 compat-v: 3.1 direct render: Yes 
Audio:     Device-1: bcm2835-audio driver: bcm2835_audio bus ID: N/A chip ID: brcm:soc 
           Device-2: bcm2835-hdmi driver: N/A bus ID: N/A chip ID: brcm:soc 
           Sound Server: ALSA v: k4.19.108-1-MANJARO-ARM 
Network:   Message: No ARM data found for this feature. 
           IF-ID-1: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IF-ID-2: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A 
           IF-ID-3: wlan0 state: down mac: <filter> 
Drives:    Local Storage: total: 145.87 GiB used: 102.90 GiB (70.5%) 
           ID-1: /dev/mmcblk0 vendor: HP model: GB1QT size: 29.81 GiB block size: physical: 512 B logical: 512 B 
           serial: <filter> scheme: MBR 
           ID-2: /dev/sda type: USB model: USB DISK 3.0 size: 116.05 GiB block size: physical: 512 B logical: 512 B 
           serial: <filter> rev: PMAP scheme: GPT 
Partition: ID-1: / raw size: 29.72 GiB size: 29.13 GiB (98.01%) used: 10.96 GiB (37.6%) fs: ext4 dev: /dev/mmcblk0p2 
           ID-2: /boot raw size: 94.0 MiB size: 93.8 MiB (99.79%) used: 37.5 MiB (40.0%) fs: vfat dev: /dev/mmcblk0p1 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Info:      Processes: 257 Uptime: 12d 21h 42m Memory: 3.48 GiB used: 1.73 GiB (49.7%) Init: systemd v: 245 Compilers: 
           gcc: 9.2.0 clang: 9.0.1 Shell: bash v: 5.0.16 running in: sshd (SSH) inxi: 3.0.37

Usually with the pi on rebooting it is a power issue. I can not tell what type of drive is connected to your USB port (/dev/sda). If it is a usb stick it should be ok but if it is some other type of drive it may be trying to draw too much power.

Some power supplies are not good enough. I always get ones that the RPi people recommend.

Thanks @Darksky. The power unit is what came with the case I bought. I agree, it is often a source of the problem. Being remote, I can't change it at the moment. Do you have any idea how I can remotely determine if that is the issue? The USB is just a thumb drive.

You really have to check the power supply. RPI4 requires 15.3W (5.1V/3A) power supply to work reliably, but I usually give a little current room to breath. I don't currently own one, but just as an example, I give my TV box which is rated for 5V/2.5A, a 5V/3A power supply so it can give enough power to external storage attached to it. DON'T CHANGE THE VOLTAGE, just the current.

I just looked it up from where I bought it. The power supply is 5V/3A from Miuzei.

Is there any way to identify power supply issues remotely?

Another thing is maybe some type of network issue. Hard to diagnose long distance.

I did try to diagnose internet connectivity - to the extent I could. I set up a ping using a VNC connection. Unfortunately, I didn't put a timestamp on it and, despite what appears to be a reboot, the VNC window looked identical (i.e., had the same windows open and the ping was still running) -- so I just restarted it.

But, as I think about it, I don't think ping via a terminal would "restart" itself after a reboot. That suggests that the Rpi4 is on the whole time and just not accessible. Of course, the results from journalctl --list-boots show 0 2a794ea919d84ef1971043a876919e95 Mon 2020-08-03 03:50:47 PDT??Tue 2020-08-04 12:41:14 PDT. That suggests it just rebooted yesterday.

Otherwise, the connection is CAT6 and a nice 400 Mbit/s connection.

Agree.

Sounds like then you need to do some network trouble shooting then when you get home. Of course your ISP could be having issues also.

Yeah, I thought that I ruled out network issues based on (1) other devices connected to the same network are accessible when the Rpi4 is not; and (2) the journalctl list showing that it rebooted after the down time ended. But now I am just confused.

Forum kindly sponsored by