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!
netsharc · 9h ago
Maybe you know this, but UPSs have signaling software to tell whomever it may concern if it has lost power and is running on battery.
For big servers, the UPS's batteries might only give minutes of power, so they'd listen for such a signal to do an orderly shutdown.
piperswe · 7h ago
> I wonder if the same approach will also work for a computer connected to a UPS. Probably not!
Considering that my UPS appears as a battery in KDE when I plug the USB cable in, I wouldn't be surprised if it's treated the same as a laptop battery across most of the stack
telotortium · 6h ago
Was the title changed since this comment? It now says “How to trigger a command on Linux when power switches from AC to battery”, which seems perfectly clear. I’m guessing “from AC to battery” was not present initially?
nemomarx · 6h ago
Yeah, it was when disconnected from power at first
Rooster61 · 8h ago
+1 to this.
This is still a logical use case, but it's not the mental image that immediately got conjured up after reading the title for me.
NooneAtAll3 · 8h ago
+1?
wkjagt · 7h ago
It's a way of signaling agreement.
Rooster61 · 7h ago
They were correcting my initial "1+"
tenthirtyam · 5h ago
Shouldn't we programmers be just typing "++"?
Rooster61 · 7h ago
Yes, thank you. Fatfingered
wildzzz · 7h ago
With that example, why not just remove the battery entirely?
As for a UPS, I have a Synology NAS that can monitor an APC UPS over its serial USB port. When the UPS loses power or is told to gracefully shutdown, the NAS also gracefully shuts down.
LoganDark · 9h ago
"on power disconnection" (event) probably would've worked better than "when disconnected from power" (time period).
nisegami · 9h ago
Computers connected a UPS can use tools like NUT or more specific tools like apcupsd. It's much more common to need to know when a UPS powered device switches to battery to trigger stuff than it is to need to know when a laptop switches to battery, so there's a lot more tooling in that area.
1718627440 · 9h ago
That's exactly how I understood the headline.
jauntywundrkind · 1h ago
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.
Const-me · 9h ago
Interestingly, a few months ago I wanted a similar thing for Windows. Ended up developing a simple tray utility for that. Probably the most important method is the handler of WM_POWERBROADCAST message: https://github.com/Const-me/SleepOnUnplug/blob/0.4/SleepOnUn...
sgt · 8h ago
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.
masom · 5h ago
This is pretty much what this solution does, but through udev.
Systemd, D-Bus, and udev can be used separately or together to make this easier to listen in userland, it will just be dependent on your distribution or setup.
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.
e40 · 5h ago
Yep, I have used apcupsd on Linux, Windows and macOS for more than a decade. It’s been triggered many times, too!
hamandcheese · 6h ago
How does it trigger the shutdown? Does it have a power switch connection to the motherboard?
treve · 6h ago
shutdowns can be done in software like 'sudo systemctl halt', so it doesn't need a line straight to the motherboard. That's the desired path because it lets running applications gracefully close and finish writing to disk.
gorgoiler · 5h ago
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
Wouldn’t this potentially leave e.g. disk encryption keys in memory?
ge96 · 6h ago
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
sigwinch · 9h ago
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.
Theodores · 6h ago
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.
jauntywundrkind · 1h ago
There's much much better Secure Boot and encrypted disk options than there used to be, which is good!!
But it does feel like the security regime is pretty lax. I feel like some BLE tracker system is a natural fit for laptops. I'd love a motion sensor alarm built in.
Framework laptop's embedded controller is open source, run Zephyr. I don't think there's a ton of peripherals it has access too, but I love the idea that one could potentially make their own firmware that has their own security designs built in.
Doohickey-d · 5h ago
M1 Macs are more theft-proof than most: it's useless if it's attached to someone else's iCloud account.
It even has parts pairing, so the e.g. the screen has some features disabled if you swap it.
ajross · 9h ago
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.
M95D · 2h ago
If you don't like udev (and I don't blame you, I hate it too), you can do the exact same thing with mdev or acpid.
imcritic · 9h ago
[flagged]
tomhow · 8h ago
Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
Please don't complain about tangential annoyances... They're too common to be interesting.
Feeling sorry for you, since that will likely lead to you missing out on a lot of good information! Not to mention the pointless stress you must be under.
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!
For big servers, the UPS's batteries might only give minutes of power, so they'd listen for such a signal to do an orderly shutdown.
Considering that my UPS appears as a battery in KDE when I plug the USB cable in, I wouldn't be surprised if it's treated the same as a laptop battery across most of the stack
This is still a logical use case, but it's not the mental image that immediately got conjured up after reading the title for me.
As for a UPS, I have a Synology NAS that can monitor an APC UPS over its serial USB port. When the UPS loses power or is told to gracefully shutdown, the NAS also gracefully shuts down.
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.
I believe Windows has something similar - also an event.
Systemd, D-Bus, and udev can be used separately or together to make this easier to listen in userland, it will just be dependent on your distribution or setup.
The kernel essentially flags the power source through udev, and the rule triggers the script. That can be done programmatically instead of a script as well. libudev is there for that: https://www.freedesktop.org/software/systemd/man/latest/libu...
https://wiki.archlinux.org/title/Udev (userland /dev is what udev does)
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.
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.
But it does feel like the security regime is pretty lax. I feel like some BLE tracker system is a natural fit for laptops. I'd love a motion sensor alarm built in.
Framework laptop's embedded controller is open source, run Zephyr. I don't think there's a ton of peripherals it has access too, but I love the idea that one could potentially make their own firmware that has their own security designs built in.
It even has parts pairing, so the e.g. the screen has some features disabled if you swap it.
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.
Please don't complain about tangential annoyances... They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html