I think you already decided what I would have recommended (just write to a log file in your python script) but I wanted to hopefully help with the rest of the question hah.

So the first thing to remember is that a pipe (|) in Linux is a unidirectional data channel that passes stdout from the left command the right command’s stdin and this is its only function. Also notable is that exit status of a pipeline is the exit status of the last command in the pipeline (unless the pipefail option is enabled but this isn’t the behavior you wanted either), this is what is available in $? as well immediately after the pipe exits in a script, problem with that is that tee can exit successfully while the previous command failed because it did its job redirecting output.

To get the behavior you are after you would probably need to write a script that does the signal handling or it might work if you use exec to wrap your python+tee command in your dockerfile because then the bash process will get replaced by python or tee, I’m not sure which or how tee will interact with exec without testing though.

Anyway, hope that helps, here are the docs on pipe which are worth a read. In fact when double checking something just now, I learned I can do |& today instead of 2>&1 | which is neat hah!

Edit: I forgot to mention, signal handing in docker is a whole other animal so depending on how you are specifically running it the behavior and signals might not be what is expected or the same as running the commands outside of docker.

Great article about it: https://medium.com/@gchudnov/trapping-signals-in-docker-containers-7a57fdda7d86

Repost if you can’t read it on medium: https://www.cloudbees.com/blog/trapping-signals-in-docker-containers

I had a few ideas, I’m suspicious that handbrake is falling back to CPU, maybe check the logs of the container to make sure it isn’t falling back to CPU decoding. Otherwise here are a few things I would check next:

• If you are not using docker locally so you are already doing this, you will need to configure the docker container to pass through the GPU for quicksync to work inside the container.
• If you are already doing that then I would make sure the device is the same name on the synology, it probably is but just to be sure.
• you will likely need to add your user to the video and/or render group on the synology if you haven’t, especially if you are running the container as your user instead of root
• make sure you are reading and writing to volumes that use bind mounts and not docker volumes, overlayfs is not what I would call fast and writing especially.

So I had a few thoughts. I’m not sure that you can use the docker device flag with a directory as you have there, I think it expects a device node, you can pass that directory as a volume (-v) though.

If that doesn’t work you might also try running the VM with host-passthrough mode set on the CPU as well if it isn’t set that way already, sometimes that is also required for pass through to work from my experience. Also, make sure you passed through the whole device node, sometimes there are audio devices you have to pass through with the GPU device or you will get odd errors like those initialization ones you had. I’m not sure if this is the case for Intel iGPU though offhand though. Are you able to use intel_gpu_top on the VM to access the GPU? None of that is necessarily specific to proxmox though (but probably applies to anything libvirt powered) so YMMV.

Edit: I realized you may not know what a “device node” is, that is the full path to the device, like /dev/dri/renderD128 vs /dev/dri which is actually a directory.

I do on some of mine because it makes some of the automation i have for them simpler to maintain when it is also applied to x86 hardware or virtual machines. It used to be a huge pain to use on a pi but it works pretty well these days, especially since about 24.04 I want to say.

All of the advice here is great but that is a Bambu printer, you should run its calibration routine again I would say and see what it says it also should be able to compensate if the bed is warped if you tell it to do bed leveling (unless the A1 doesn’t do that, I think it does though).

Also, when you say collisions is the printer colliding with itself or the part? You can also run an homing routine and manually move the hotend around to see if it has issues.

Also RE the local event, is the air temp really hot where you are? You might need extra part and hotend cooling if the ambient temp is like 40C or something. I mean like tweak the slicer not put an external fan on it necessarily hah.

In case anyone here doesn’t follow it, Ivan’s YouTube channel is awesome, he has been working on a crazy marble clock: https://youtu.be/K3FMVmAte3g

ProperPrinting is also great, he has some cool videos on custom extruders and printers he designed and a wild extruding resin printer with UV lasers.

As others have said, be careful with fans if they are large, many of the plugs don’t have a very high wattage rating and are all definitely rated for 15a at max usually, you might consider a smart relay instead (like a Shelly or something).

That said I have switches and plug-in and in-wall relays from Aqara (zigbee) and TP-Link (WiFi) and zooz (zwave) and all are fine and do the job. Not all support power monitoring if that is something that matters to you, it’s not a universal feature.