Secondary ACPI daemon for user control

[Dae Quan]

Hi Stephan,

I’m working in a solution to control Lightwhale when it’s running as a VM. And this is my solution:

• Configure a secondary ACPI daemon to catch the events “poweroff” and “reboot”.
• After that run inside it one container with the vm-client-tools to send the corresponding events to this new ACPI daemon.

After my initial testing I’ve solved the first part. So I want to share it with you. The idea is to add it to the mainstream if you agree with this strategy.

The changes are minimal:

(1) Add the file /etc/acpi/events/restartbtn with this simple content:

event=button[ /]restart
action=/sbin/reboot

(2) And create a new service script like /etc/init.d/S02acpid-vm with this code:

#!/bin/sh
#
# acpid-vm        Starts a secondary acpid daemon with user level event file.
#

# Usage:
#  - Poweroff : $ echo "button/power"   > /var/run/acpid-vm.event
#  - Reboot   : $ echo "button/restart" > /var/run/acpid-vm.event

DAEMON=acpid-vm
EXEC="/usr/sbin/acpid"
PIDFILE="/var/run/$DAEMON.pid"
PID2FILE="/var/run/$DAEMON-lock.pid"
SOCKFILE="/var/run/$DAEMON.socket"
PROCFILE="/var/run/$DAEMON.event"

ACPID_ARGS="-e $PROCFILE -s $SOCKFILE -p $PIDFILE -S -l"

[ -f $EXEC ] || exit 0

umask 077

start() {
        printf "Starting $DAEMON: "

        # Create the new pipe event file
        [ -p $PROCFILE ] && exit 1 || rm -rf $PROCFILE && mkfifo $PROCFILE

        # Open the file in WRITE mode in order to not close it while the daemon will read it
        tail -f /dev/null > $PROCFILE &
        echo $! > $PID2FILE

        # Start the ACPID listening over the new alternative file
        $EXEC $ACPID_ARGS

        # Write one (empty) line to start processing events
        echo "" >$PROCFILE

        echo "OK"
}

stop() {
        printf "Stopping $DAEMON: "
        kill -9 $(cat $PID2FILE)
        kill -9 $(cat $PIDFILE)
        rm -f $PROCFILE
        rm -f $PIDFILE
        rm -f $PID2FILE
        echo "OK"
}

restart() {
        stop
        start
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        restart
        ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

Please, note that this solution doesn’t add any new tool to the distribution. It only starts a new instance of the current acpid binary using a new FIFO to process the commands. This file is configurable, but I have selected /var/run/acpid-vm.event. So if you send button/power or button/restart to this control file you will trigger the corresponding command.

You agree with this proposal?
I’m sure you can improve the script. But an skeleton is provided, and it works as expected.

Please comment!

‌

[Dae Quan]

Hi Stephan,

I have found a different method to trigger shutdown/restart from within a container. So first of all, please discard the idea of adding the service /etc/init.d/S02acpid-vm. Anyway, I continue suggesting to add the file /etc/acpi/events/restartbtn. That’s because with it you can launch using ACPI buttons not only the poweroff action, but the reboot as well. It’s a minimal text file, so don’t worry about the size.

The method to trigger shutdown and restart actions from within a container is by using these commands (as root):

• reboot: sudo kill -s SIGTERM 1
• poweroff: sudo kill -s SIGUSR2 1

This works because you’re using the init binary from Busybox. Therefore, sending these signals to the process 1 (init) you achieve the desired behaviour.

Check the code here:

https://github.com/brgl/busybox/blob/abbf17abccbf832365d9acf1c280369ba7d5f8b2/init/init.c#L825-L831

I’ll share more information when I complete the container creation. In the meantime I suggest to add the /etc/acpi/events/restartbtn file and discuss about a direct method to start/stop one specific container before others. The problem is how do to initiate the virtual-client-tools container before others. Any idea?

[Dae Quan]

Hi Stephan,

I suggest to close this issue, because the other one “Run vm guest tools in a container automatically” supersedes it.

You agree?

Anyway, I recommend to add the file /etc/acpi/events/restartbtn because some environments use the restart button acpi event.

[Stephan Henningsen]

Hi. I'm closing it because I find them original idea a bit is too much of a hack, and that it is targeting only a single use case, and that that use case involves proprietary software.

There has to be better solutions, and I’m glad that your appear to have found one of them =)

[Dae Quan]

Hi Stephan,

Ok. But please don’t forget to add the simple /etc/acpi/events/restartbtn file.