Host controls missing when running in container

[AndreKR]

Fluidd Version

v1.35.0-e17b3de

Browser

Chrome

Device

Laptop

Operating System

Windows

What happened

My fluidd instance does not show host controls:

 
This is because fluidd assumes it cannot control the host if system_info.virtualization.virt_type is "container":

fluidd/src/components/common/SystemCommands.vue

Lines 170 to 172 in 205f8f5

	get canControlHost (): boolean {
	return this.systemInfo?.virtualization?.virt_type !== 'container'
	}

But there is no reason for this. If the Moonraker container is properly set up, with access to the hosts DBus socket and [machine] provider configured accordingly, then Moonraker can control the host just fine.

When using prind, probably the most common Klipper setup after KIAUH, the Moonraker container is by default configured appropriately.

The only case where the host commands would for sure not work is when system_info.provider is "none".

From the Moonraker docs:

If the provider is set to "none" service action APIs will be disabled.

What did you expect to happen

Host controls should be shown.

How to reproduce

Connect fluidd to a Moonraker running in a Docker container, for example by using prind.

Additional information

No response

[pedrolamas]

Hi @AndreKR thank you for opening this issue.

This is actually "by design" as Moonraker currently does not support reboot/shutdown when running inside a container.

Here is the code for reference:
https://github.com/Arksine/moonraker/blob/3129d89f0f951d475aa86f303c1ef9b6a612cb73/moonraker/components/machine.py#L305-L310

I recommend that you open a ticket directly with Moonraker as we would first need API support for this to work before we can show these options.

[AndreKR]

Hm, that's weird, because when I tell it to shut down from KlipperScreen or manually send the machine/shutdown command to Moonraker, it shuts down without issue.

I will have a look why that is, despite the code you linked.

[AndreKR]

Ok, so I found out what's going on. Everything refers to the machine.py file.

During __init__, system_info.virtualization is set to the result of _check_inside_container(). That function runs two tests to see if it's running inside a container and if it is, then it would, as a side effect, set self.inside_container. However, both tests fail, so virtualization remains "none" here and self.inside_container remains False.

Later during component_init, a provider-specific check_virt_status() function is called, which in my case asks systemd whether it is running inside a container and systemd says yes, so that's why fluidd gets "container" in system_info.virtualization.virt_type.

This later function never sets self.inside_container, so that remains False forever and that's why the shutdown commands work.

So there might be some container setups where self.inside_container gets set to True during __init__ and thus the shutdown commands would be disabled, but mine (and all other prind users') isn't one of them.

[pedrolamas]

Thank you for following up on this and finding more information, @AndreKR.

I believe that behavior to be incorrect as it can lead to a state inconsistency in terms of running inside a container or not, and thus the expected behavior doesn't match.

This will first have to be dealt with on Moonraker side to make sure the behavior is consistent.

After that, I will be happy to comply with the information Moonraker supplies and implement the correct behavior in Fluidd.