[HN Gopher] How to trigger a command on Linux when power switche...
       ___________________________________________________________________
        
       How to trigger a command on Linux when power switches from AC to
       battery
        
       Author : Mr_Minderbinder
       Score  : 58 points
       Date   : 2025-07-31 10:03 UTC (12 hours ago)
        
 (HTM) web link (dataswamp.org)
 (TXT) w3m dump (dataswamp.org)
        
       | Apreche wrote:
       | 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 cafe. 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!
        
         | nisegami wrote:
         | 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.
        
         | netsharc wrote:
         | 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.
        
         | LoganDark wrote:
         | "on power disconnection" (event) probably would've worked
         | better than "when disconnected from power" (time period).
        
         | 1718627440 wrote:
         | That's exactly how I understood the headline.
        
         | Rooster61 wrote:
         | +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 wrote:
           | +1?
        
             | Rooster61 wrote:
             | Yes, thank you. Fatfingered
        
             | wkjagt wrote:
             | It's a way of signaling agreement.
        
               | Rooster61 wrote:
               | They were correcting my initial "1+"
        
               | tenthirtyam wrote:
               | Shouldn't we programmers be just typing "++"?
        
         | wildzzz wrote:
         | 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.
        
         | piperswe wrote:
         | > 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 wrote:
         | 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 wrote:
           | Yeah, it was when disconnected from power at first
        
       | ajross wrote:
       | 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 wrote:
         | 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.
        
       | sigwinch wrote:
       | 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.
        
       | Const-me wrote:
       | 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...
        
       | imcritic wrote:
       | [flagged]
        
         | tomhow wrote:
         | _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._
         | 
         | https://news.ycombinator.com/newsguidelines.html
        
         | 47282847 wrote:
         | 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.
        
       | sgt wrote:
       | 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 wrote:
         | 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.
         | 
         | 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)
        
       | jahrichie wrote:
       | 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.
        
         | hamandcheese wrote:
         | How does it trigger the shutdown? Does it have a power switch
         | connection to the motherboard?
        
           | treve wrote:
           | 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.
        
         | e40 wrote:
         | Yep, I have used apcupsd on Linux, Windows and macOS for more
         | than a decade. It's been triggered many times, too!
        
       | ge96 wrote:
       | 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
        
       | Theodores wrote:
       | 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.
        
         | Doohickey-d wrote:
         | 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.
        
         | jauntywundrkind wrote:
         | 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.
        
       | gorgoiler wrote:
       | 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_...
        
         | 47282847 wrote:
         | Wouldn't this potentially leave e.g. disk encryption keys in
         | memory?
        
       | jauntywundrkind wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-07-31 23:01 UTC)