I’d use the same baseline approach for logs and compare counts instead of reading lines. Count yesterday’s warnings per unit with journalctl --since yesterday -p warning -o json | jq -r ._SYSTEMD_UNIT | sort | uniq -c, then alert on any unit missing from the baseline or whose count more than doubles. For network traffic, record process and remote address pairs from ss -tnpH state established every few minutes and alert on a pair the baseline doesn’t have.

Drafted with AI.

For monitoring, I’d start with alerts on changes you didn’t make. Save a baseline of listening ports with ss -tlnp and of running containers with docker ps --format '{{.Names}} {{.Image}}', then have a daily cron job compare both against the baseline and push any difference to your phone with ntfy.

Keep the baseline files outside your Docker volumes.

Also send a notification on every successful SSH login with a short script in /etc/ssh/sshrc that posts to the same ntfy topic.

Uptime Kuma covers whether Nextcloud, Immich, and DocuSeal are still reachable through the tunnel, and it can send its alerts to ntfy as well.

Drafted with AI.

https://www.samsung.com/tw/support/computing/about-49-inch-odyssey-oled-g9-display-troubleshooting (OLED G9)

Under the no-picture item it says to check whether the PC supports standard DP 1.4, and if it doesn’t, to set Menu > System > DisplayPort Ver. to 1.2 or 1.1 and reconnect the cable. The menus are probably different between the Neo and OLED models.

Your ‘-1’ comes from the Intel driver, where modeset is an integer and -1 means the driver default. OP has an RTX 5070 Ti, and ‘nvidia_drm’ modeset is a boolean, so ‘/sys/module/nvidia_drm/parameters/modeset’ reads ‘Y’ or ‘N’. Files under ‘/sys/module/*/parameters’ show the value the loaded module is running with.

False. Samsung’s own troubleshooting page for the OLED G9 tells you to go to Menu > System > DisplayPort Ver. > 1.2 or 1.1, then reconnect the cable when the host doesn’t negotiate DP 1.4 cleanly. Users on the Neo G9 report the same OSD option, having dropped the DP setting to 1.2 and 1.1 (OSD) while troubleshooting a no-signal problem. Dropping the version is a standard troubleshooting step. At 1.2 the monitor stops requiring DSC and HBR3, so if link training is the problem the port will often show up as connected even though 240Hz won’t be available.

And nvidia_drm.modeset is a kernel bool parameter, and sysfs renders bools as Y or N.

Set the DisplayPort version in the G9’s on-screen menu to 1.2, replug the cable, and check whether xrandr shows that DP output as connected.

If it still shows disconnected, replug the cable and right after run:

sudo journalctl -k -b | grep -i -E 'nvidia|drm'

Look for link training or EDID errors on that connector.

Also run cat /sys/module/nvidia_drm/parameters/modeset and confirm it returns Y.

Drafted with AI.

2a06:98c0:3600::103 is the address Cloudflare uses as the client IP for requests sent from a Worker, so these probes most likely come from someone else’s Worker and have nothing to do with your DNS-only records. Cloudflare also adds a CF-Worker header to every Worker subrequest, set to the zone name of the account that owns the Worker. I’d log that header in your reverse proxy, then send the zone name and a few sample requests to Cloudflare’s abuse report form. You can also drop any request that carries a CF-Worker header, since your Lemmy instance shouldn’t need traffic from Workers you don’t run.

Drafted with AI.