GUIDE: Setting up remote logging

General
1

My PiFi device refused to create its Wi-Fi network, leaving me with no way to connect and troubleshoot the issue. I was stuck. I didn’t want to factory reset the device before understanding what went wrong (and actually no longer had a way to factory reset, but that’s a different story). Even when I eventually managed to get it running after three restarts, I realized that commands like logread and dmesg only showed logs from the current boot session. By that time, I had lost all the valuable information about the previous failures, and I had no way of determining what had caused the problem in the first place.

The Solution: External Syslog Server

To ensure you have access to older logs, the best solution is to forward your logs to an external syslog server. There are two main ways to achieve this:

  1. Docker-based Syslog-ng:
    You can install a Docker container running syslog-ng on your network (on a different computer on the network, not on the PiFi device). This container acts as a centralized syslog server, receiving logs from your OpenWrt device.
  2. Built-in Syslog Server on Unraid:
    Alternatively, I opted to use the built-in syslog server on my Unraid server.
    Either approach works, but the key is that you should have another computer on your network that can receive and store the logs. Alternatively, you can plug a small USB thumb drive and have the logs persist there, I didn’t have one to spare, maybe I’ll do that as well in the future.

Setting Up Your Syslog Server

While configuring your syslog server, you need to decide on a location—a “syslog folder”—where all incoming log files will be saved. In my setup, I created a folder with SMB access so that I can easily access and review the logs from any computer on the network.

My syslog server was configured to listen on port 514 (the default for syslog). Once the server was ready, all I had to do was log into my OpenWrt’s LuCI interface and navigate to:
LuCI → System → System → Logging
Under the “External System Log Server” section, I simply entered the IP address of my Unraid machine (for example, 192.168.1.69).

Testing the Setup

After setting everything up, testing was straightforward. From an SSH session on the PiFi device, I ran:

logger "test message"

This command sends a test log message to the external syslog server. I then checked my designated syslog folder on my network, and sure enough, the “test message” was recorded in one of the log files.

And there you have it, even if my PiFi device now crashes or reboots, I will still have its last thoughts before it gave up and crashed…

2

Hey,

If it’s just not broadcasting AP and USB recovery is disabled - the two ways would be:

  • Connect a USB-to-ethernet adapter (which runs over LAN so you can then connect a cable to your computer and visit 192.168.3.14) or
  • Connect monitor/keyboard to Pi and it shows shell too

Still, remote logging may be useful for certain situations

In early testing there was an option where:

  • If USB removed, broadcast internal wireless as AP (if system is indeed running)

But it was less recoverable in certain situations where a misconfiguration prevented simply replacing /etc/config/wireless from fixing. But it does retain packages at least. And there have been far less unrecoverable issues with the more aggressive USB performs hard reset.

There might be a more elegant solution somewhere in-between, worth exploring and open to suggestions

3

I’m currently working on a new solution.
I recently purchased a small 64GB Sandisk USB thumb drive for just a few dollars and updated my automatic backup script to store backups on both this USB drive and my original cloud folder.
I then created a monitoring script that checks the USB connection: if this drive is disconnected, the script logs the event and triggers both LEDs to blink as an alert. If the drive is reconnected within 5 seconds, it automatically restores the most recent backup from the USB drive. After 5 seconds, the LEDs return to normal, and reconnecting the drive won’t trigger a restore.

This approach offers several advantages:

  1. It restores the most recent working configuration instead of reverting to factory defaults, and I can easily access the backup file by plugging the USB drive into any computer. Sure, I could revert to factory defaults and then restore the backup, but I like shortcuts wherever I can.
  2. It prevents immediate, automatic restoration upon disconnection, giving me a brief window to cancel the process if needed.
  3. The LED indicators (or corresponding log entries available via cloud storage) clearly show if and when the restore script has been triggered.

When traveling, without access to a monitor & keyboard (and without the USB-to-ethernet cable which I didn’t get yet, but intend on getting), this I believe is the ideal solution for my needs. I’ll continue testing it, and once I’m satisfied with its performance, I’ll share the script if someone else will be interested in it.