I wrote a guide for using dockers, effectively, to control multiple printers using a single computer.
I felt it was different enough from the excellent discussion in https://community.octoprint.org/t/multiple-printers-per-server-megathread , because that approach doesn't touch dockers at all and i didn't want to get lost buried in that huge-120-page discussion (if the moderators feel it could/should be merged into that thread, by all means go for it).
Dockers are awesome and once you get the usb quirks ironed out, there is remarkably little work to get multiple instances running effectively (and predictably).
did you verify that if you disconnect and reconnect printers in a different order, that the symlink handle the octoprint server will be used instead of de-referencing the underlying device ?
lets say it created /dev/octo_foo that points to /dev/ttyACM0. and /dev/octo_bar pointing to /dev/ttyACM1
then you disconnect and reconnect such that foo points to ACM1 and bar points to ACM0.
Without restarting the servers.
The octoprint server that uses /dev/octo_foo, after reconnect would it use the correct underlying device ?
I use another serial device connected to my rpi and to solve the “music chair problem” you can just use the /dev/serial/by-id serial port, instead of the ttyACM that is fixed and unique (maybe not?!?) by device.
the /dev/serial/by-id folder contains symlinks to the /dev/ttyACM devices, which are created after the /dev/ttyACM device are created. (like in the udev rules)
unique - yes.
fixed - no.
the udev rule in the tutorial creates similarly unique symlink, but unlike the other script, it also bounces the server to ensure it points to the correct device - that is a must for a docker container, because mapped symlink to devices are dereferenced.
to be honest, i didn’t test if running octoprint without a container would refresh the device if it was using a symlink instead of the actual device.
I only ran octoprint directly once, it created a ~/.octoprint folder for its data and files.
looking back, there should be a flag for running it with a different home folder.
my personal preference is going the official docker route when possible, especially for long running services. i let the maintainers deal with all the packaging quirks. it also makes future upgrades easier.
about that script, it looks very well thought out, and a lot of clever work went to it.
however, i rarely give root access to scripts off the web, especially when they involve changing system files. if i just need to update a udev file, i rather do it myself.
I wrote the octoprint_deploy script, and while I understand the hesitation one may have about giving root access to the script: 1. Everything is open, so if there were anything malicious, someone/anyone/everyone would find it. 2. Every time someone installs the OctoPi image they are running scripts from off the internet.
I meant no disrespect if such was felt.
As i mentioned, it looked impressive and if it were not buried in the mega thread I might have noticed it before going the docker route. Feel free to create a tutorial for your script so it is easier hopefully to find, or an instructable. (Let me know if you do so i would link to it. I am not making money here on this).
For someone who likes containers it is a natural route to follow, the only "bump" i encountered was dereferenced device symlink so I learned something new.
There are many ways to cook this stew. All with their pros and cons.
The biggest negative about the docker route imo is that the servers restart when a printer is reconnected. Looking at my log, that happened a month ago , so for me its fine.
since we are on the subject of reconnecting printers. If octoprint is run directly and it uses a device symlink, would it switch to the correct device upon reconnect?
No. It is all about having some identifier in the udev rule so the symlinks are always the same. I use either SerialNumber or in cases where that is lacking, I use physical USB port address.
Stand-alone tool for generating this automatically by plugging in the printer:
I think we might be talking about different things.
The corner I ran into with containers was the musical chair problem.
My udev rule is very similar to the one your script generates, it identifies a printer based on serial number.
lets neglect the creality case where there is no serial number (due to contracted manufacturing probably of the boards).
But to ensure the server always uses the correct device, i added a RUN command to the rule that restarts the container. (In the container case, it is a must because the symlink is dereferenced and the actual device is mapped to the container. )
Now, if octoprint is running and uses
and foo points to dev/ttyACM0
now for some reason you disconnected all the printers and reconnected them and now
foo points to /dev/ttyACM1
would octoprint which is still running and unaware to the switcharoo, when using foo, would it be using correctly ttyACM1 or would it hold on to ttyACM0 and start printing to the wrong server.
It really depends if the octoprint code detected the broken connection and how handles reconnection.
i am not sure how the serial library handles closed devices and if it would allow to keep writing to the serial port without closing the stale connection and recreating a fresh one.
the only way it to find out is to try.