mharsch

#!/bin/bash

# Script for wiping old plot directories and prepping drives for new plots
# Pause between steps in case something goes wrong (Ctrl-C to bail out)
RANGE=sdb[g-j]

DEVS=/dev/$RANGE
DEVS_SCHED=/sys/block/${RANGE}/queue/scheduler
PARTS=/dev/${RANGE}1
OLD_DIRS=/plots/${RANGE}1

mharsch

This will save you from going down a rather deep documentation rabbit hole:


1.) enable pcspkr driver by removing blacklist entry for pcspkr in /etc/modprobe.d/blacklist.conf
2.) create user group 'beep' for controlling permissions to speaker
	sudo addgroup --system beep
3.) Add your user account to the new beep group (logout and log back in after this step)
	sudo usermod -aG beep $USER
4.) change default permissions on speaker device to allow members of group 'beep' to access speaker.
    Comment out previous entry and add the following line to /usr/lib/udev/rules.d/70-pcspkr-beep.rules

mharsch

Uses this container to scrape power data from the reverse-engineered kasa API running on the smart plugs (e.g. HS100).

Docker compose example

compose.yml

version: '3.8'

mharsch

Most online instructions for Linux watchdog refer to the 'watchdog' package which is best described here

The watchdog configuration described here uses systemd, and the two methods are mutually exclusive, so if you've previously setup the above watchdog, you must first uninstall it.

sudo apt remove watchdog

Our goal is to add a systemd service that continuously pings a known host (or IP address)

mharsch

/**
 * V. Hunter Adams
 * DDS of sine wave on MCP4822 DAC w/ ISR
 *
 * Modified example code from Raspberry Pi
 * Copyright (c) 2020 Raspberry Pi (Trading) Ltd.
 *
 * SPDX-License-Identifier: BSD-3-Clause
 *
   GPIO 8 (pico pin 11) MCP4725 SDA

mharsch

RTX 3080 Ti System:
===================
OS="Ubuntu 22.04.2 LTS 5.15.0-70-generic"
SystemVendor/Model="Gigabyte Technology Co., Ltd. B550 AORUS MASTER"
CPU="1x AMD Ryzen 9 5950X 16-Core Processor (C:16|T:32)"
GPU="NVIDIA GeForce RTX 3080 Ti"
GPUSKU="Ampere"
GPUArch="N/A"
DriverVersion="530.30.02"
PCIeLink="PCIe 4x16"

mharsch

#include <math.h>

// connected to 'D+' pin on mini USB
const int input_pin = 11;
// connected to 'D-' pin on mini USB
const int output_pin = 12;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);

mharsch

Deprecated

I no longer recommend the below method. For my updated recommendation, see this gist

Setup Linux to reboot if it loses access to a certain host by hostname (not IP)

The linux watchdog service can be configured to run certain 'liveness' tests periodically, and then take some action (such as reboot) if a test fails (and doesn't recover) for some period of time.

There is a built-in test for pinging an IP address (i.e. 'ping' directive), but you may instead need to test access to a hostname

mharsch

If you have a failure mode that can be diagnosed by a high rate of messages flooding the system log,
you can use the script below in conjunction with the watchdog service to detect the condition
and reboot if it persists.  This is a pretty big hammer, but potentially better than just rebooting on
loss of network or some other arbitrary liveness test.

add a 'test-binary' line to /etc/watchdog.conf pointing to this script (will be treated as V0 test script
with no corresponding repair script).  Also, set 'interval' to something like 20 seconds (at least greater than
the sample period in the script).

You can convince yourself it's working (once the watchdog service has been restarted with the above config)

mharsch

We want to run a long-running process during certain hours, days-of-the-week, etc.
We want the service to start on a schedule, and be stopped on a corresponding schedule.

Example: Residential electric rates are based on Time of Use (TOU) such that Weekdays
from 1p to 7p are considered 'Peak Hours' when rates are much higher than all other times.
Our long running process uses significant electricity, so we want to stop running it
once we reach the Peak Hours period, and resume running once the Peak period is over.

1.) We create a systemd service file for the long running process (foo.service)
2.) We create a systemd timer unit associated with the service (foo.timer).  This timer handles