Comment 5 for bug 1349566

Revision history for this message
dann frazier (dannf) wrote :

You're right, it is calling /sbin/poweroff, I made a wrapper to see what was going on there as you suggested. While using the wrapper (to prevent an actual poweroff), I noticed:

- 'udevadm monitor -e' logs no events
- No arguments are supplied to /sbin/poweroff
- '/sbin/poweroff' gets called multiple times (I counted 70 times)

Now, I'm not sure what explains the latter, but here's a guess. The event device that systemd-logind is listening to is exposed by the gpio-polled keybard driver, which I believe means that the GPIO line is polled at a regular interval and, if triggered, results in the kernel synthesizing a poweroff keyboard code. Perhaps it generates a new press each time it is polled and found to be asserted.

I also notice that if I make the wrapper a 1-and-done - i.e., I set a flag the first time we're called and turn subsequent /sbin/poweroff calls into no-ops, things behave as expected - swapoffs and umounts before powerdown.

So, it seems like multiple poweroff calls in succession result in the described behavior, is that expected? I wonder if you'd be able to reproduce this by nintendo advantaging a poweroff wrapper that does rapid-fire non-blocking calls to the real poweroff?

We could also experiment with asking the vendor to workaround this in firmware (assuming this is considered a bug) by disabling autorepeat and increase the poll interval to something higher.