FR: compatibility for systemctl when running inside docker container

[vajonam]

Since running in a docker container usually doesn't use systemd/systemctl and uses supervisord insteald, I have hacked up a bit of script to simulate the output for systemctl to allow the fluid UI to retain is functionality.

Do you have any interest in adding this to machine.py? I see there is some beginnings of container support in there. I can add one if you think it's useful for others?

#!/bin/bash 
SUPERVISOR="supervisorctl -s unix:///tmp/supervisor.sock"
SERVICE_STATUS=`${SUPERVISOR} status klipper moonraker |  awk '{print tolower($0)}'`
KLIPPER_STATUS=`echo $SERVICE_STATUS  | awk '{print ($2)}'`
MOONRAKER_STATUS=`echo $SERVICE_STATUS | awk '{print ($8)}'`

if [ $1 == "list-units" ] ; then
        echo "moonraker.service                                           loaded    active   ${KLIPPER_STATUS} Starts Moonraker on startup"
        echo "klipper.service                                             loaded    active   ${MOONRAKER_STATUS} running Starts klipper on startup"
        exit 0
fi

if [ $1 == "show" ]; then
echo "active
${KLIPPER_STATUS}

active
${MOONRAKER_STATUS}"

exit 0
fi

if [ $1 == "restart" ] ; then
        if [ $2 == "klipper" ] ; then
                $SUPERVISOR restart klipper
        fi
        if [ $2 == "moonraker" ] ; then
                $SUPERVISOR restart moonraker
        fi
        exit 0;
fi

[pedrolamas]

Not sure how I missed this before, but here's my own take on creating a systemctl script to control supervisord (be aware that my version links klipper and simulavr together!):

https://github.com/pedrolamas/docker-klipper-simulavr/blob/41bb258b9a8e67fae570fe9124360c13ddd8b0e0/rootfs/bin/systemctl

Having said that, I just noticed that a supervisord support was added directly to Moonraker in #548, so I guess we should start using that instead!

[Arksine]

Yes, the supervisord provider should be used rather than a wrapper around it. FWIW, I am currently working on some improvements for the supervisord provider, after doing my own testing I realized that the original submission was broken. I anticipate that the linked branch will be merged soon.

[pedrolamas]

I'm not 100% sure we will be able to directly use supervisord in a situation where klipper is being used with simulavr (such as my tests docker image), reason being that when klipper restarts, we also need to restart simulavr, and I believe there is no such out of the box mechanism in supervisord for that (a small script might do the trick though)

Edit: Supervisor Events might be an option too!

[Arksine]

Why is it necessary to restart simulavr? When testing against Mainsail's virtual printer container I was able to restart Klipper, but perhaps I'm missing something. TBH I'd like to see a better option than simulavr, I may look into a basic "virtual mcu" that isn't a full simulator. That said, I do think that the events will work for you.

[pedrolamas]

Why is it necessary to restart simulavr?

From my tests and @th33xitus, klipper will not work on restart if we don't restart simulavr before.

When testing against Mainsail's virtual printer container I was able to restart Klipper, but perhaps I'm missing something.

It's the same script as mine, as @th33xitus and I collaborated on this for quite a while! 🙂

https://github.com/mainsail-crew/virtual-klipper-printer/blob/6254b504547cea5ebe0ac4d4fdb2bf480f62c6f4/scripts/service_control.sh#L79-L86

TBH I'd like to see a better option than simulavr, I may look into a basic "virtual mcu" that isn't a full simulator.

That makes 2 of us, and the best I have so far come up to is my virtual_pins klipper module.