17 comments

[ 3.0 ms ] story [ 37.6 ms ] thread
The headline is a bit misleading. I thought it meant it was about triggering a command on a computer that has no power, which is obviously impossible.

What it’s actually about how to automatically automatically trigger a command on a Linux computer (almost certainly a laptop) in the event that it switches from AC power to battery power.

The example given is your laptop is plugged it at a café. Someone steals it, which involves unplugging it from the wall. At the moment it is unplugged it automatically shuts down, locks itself, etc.

I wonder if the same approach will also work for a computer connected to a UPS. Probably not!

>. Someone steals it, which involves unplugging it from the wall. At the moment it is unplugged it automatically shuts down

You could achieve same thing if you unplug your battery.

Thanks for reporting, I updated the title, I hope it will be clearer for new readers.

For the APC, use nut :)

So for those who want the tl;dr: The answer is just "use a udev rule".

Udev is one of those classic open source tools that is immensely powerful and gracefully well designed, with all sorts of emergent power...

...that ends up being an obscure bit of graybeard prestidigitation purely because of it's awful syntax.

No really, there's a very clean mapping between the state in sysfs and the resulting uevents produced. You just can't tell because of the way it looks.

udev is useful for customizing all sorts of ergonomics. My example: when my keyboard/mouse switches from one machine to another, control signals are sent to each monitor. This mimics a very expensive 8k DisplayPort KVM.

So that’s an option rather than power. Devise where you’d place a YubiKey on an extension cord, with its removal triggering logout and shutdown.

[flagged]
the irony of starting your statement by self-applying a pronoun seems lost on you
On macOS this is elegant and efficient by listening to OS level notifications into userland. Tapping into IOKit - namely IOPowerSources and IOPSNotificationCreateRunLoopSource - is trivial and will notify you when there is a power source event.

I believe Windows has something similar - also an event.

I use an APC with a management cable, triggers graceful shutdown and startup on reconnection. It also e-mails me and stores a log. I prefer this approach so 99% of ecosystem isn't on the server, you can let your server do server things and not be the battery police.
I remembering profiling battery life on a chromebook that I put GalliumOS on. When it would be on timestamp, off timestmap and then it would tally up runtime in hours/minutes, nasty bash
It is interesting how laptops, whether running a consumer operating system or Linux, are poorly protected from theft. There is the Kensington lock hole that nobody uses and that is about it. Really, any laptop needs to be a brick without the magic password or bio-id, if the owner has configured it to be so when stolen, as identified by a change of power source or other cause.

As it is, all you need is a screwdriver to take out the disc, put it in another box, format it and put it back. Then you have a machine good to sell on eBay.

NFC could be another way of protecting a PC so you need your phone to unlock it.

PCs used to have a low grade lock on them originally, that locked the power button and disks behind a flimsy piece of plastic. This feature was soon dropped.

Clearly the market does not demand theft proofing. Otherwise we would have a little bit more than noble efforts like this udev script.

Problem with theft-proofing is it inherently comes at the cost of both repairability and recyclability. If every part is cryptographically locked to its parent machine, you can't scrap devices for parts.

Sometimes there's "unlock before recycling" flows but generally people are pretty unlikely to know they should do that, and even less likely to remember to do it.

Pah! Shut the system down like a real BOFH! Use the Magic SysRq Key interface to instantly crash the system:

  echo 1 > /proc/sys/kernel/sysrq
  echo o > /proc/sysrq-trigger
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
You'd probably want to do the filesystem unmount dance first:

  echo 1 > /proc/sys/kernel/sysrq
  echo u > /proc/sysrq-trigger
  dmesg --follow \
  | grep -qm1 'Emergency Remount complete'
  echo o > /proc/sysrq-trigger
...least putting a bit too much trust in ext4/btrfs/zfs journalling.
That's neat, I'd never considered one could use udev reactively like this! Very nice.

Not nearly as elegant, but I keep running into problems where I want to run some command when X happens. I've been trying to lean into systemd, creating a service for whatever it is I want run (perhaps just a oneshot if it's a a one off command). Then have a separate program that detects for the desired condition (polling?) and runs systemd-notify to signal that it's healthy. Then you can just BindTo=, so that the desired command runs whenever the condition-detector thing goes green.