Linux DietPi 6.6.56-current-rockchip64 #1 SMP PREEMPT Thu Oct 10 10:50:06 UTC 2024 aarch64 GNU/Linux
Architecture | dpkg --print-architecture
Arm64
SBC model | echo $G_HW_MODEL_NAME
ROCK 4 (aarch64)
Power supply used : USBC power supply
SD card used: Onboard eMMC
Additional Information (if applicable)
Software title: Octoprint
Was the software title installed freshly or updated/migrated? : Fresh install
Can this issue be replicated on a fresh installation of DietPi? Yes
Steps to reproduce
Start with a clean DietPi install
Install Octoprint through DietPi-software
Go to dietpi:5001, walk through setup questions without restoring a backup
Finish setup, notice Octoprint is working fine on port 5001 (as mentioned in documentation)
In the Octoprint configuration panel, restore a backup from another system (in my case my formal OctoPi setup on a RPI3)
After restart, Octoprint is running, but now on port 5000 in stead of 5001
Expected behaviour
I would expect Octoprint to run on the same port (5001) as before restoring the backup, and as documented
Actual behaviour
after restoring the backup, Octoprint is running, but on port 5000
Extra details
Apart from the different port, Octoprint seems to run fine and includes all settings as expected from the backup, e.g. restore was successful. Nothing else is running on port 5001 . I can’t find any way inside Octoprint or its configuration to manually set a port number, so this looks like something set by DietPi.
No, it did not contain any specific port configuration (it could be listed under the ‘server’ key).
That reminded me that Octoprint has some cli-tooling of itself. And sure enough:
octoprint config get server.port returns 5000.
Similarly, setting it with octoprint config set server.port 5001 and running dietpi-services restart octoprint enables octoprint again on port 5001.
I could mark this as ‘the answer’, but I don’t think that restoring a backup should set a different server port? Perhaps DietPi should do something so that even after restoring a back-up octoprint is still available on the 5001 port as mentioned in the documentation?
So the backup overrides the config, where the custom port was set (see).
So instead we could start it with octoprint serve --port=5001, but it overrides whatever the config says.
I’m not sure if this is better default behavior, it confuses even more if you try to change it in the config file and it does not apply.
I tend to agree… So the better option would be to ensure Octoprint does not change the port number when restoring the backup? That would be something to take back to the Octoprint community forum then…
On another thought… DietPi decides what runs on which port. That will probably match defaults, with exceptions as this in some cases. Is there an easy way to manage (inside dietpi) what runs on which port? I could image having something like dietpi-ports where you can co trol what runs on which port, using cli flags for underlying commands so that app-local config is indeed ignored. But instead embrace the fact that Dietpi is in control of software installed through dietpi-software and ensure it behaves as documented, or let users manage it on their own.
Each software has a own app specific configuration files where usually an app port is specified. This is nothing you can control from operating system point of view.
And honestly, restoring the configuration file might be expected as it is probably part of the backup.
Question is, where was the backup taken? On which system? Does the original system, that has been backed up, does it had port 5001 set? Yes or no? If yes, it would be a question to app developer why the port was not saved.
Does the original system, that has been backed up, does it had port 5001 set? Yes or no?
No. Octopi apparently uses Octoprints default port (5000). However, you never had to explicitly specify a port number, it was abstracted away by OctoPi and you could just navigate to octopi.local (without port number).
If yes, it would be a question to app developer why the port was not saved.
It could still be… If they would have explicitly saved the port number 5000 to the configuration file, I would have found it there. Now it was implicitly using the default value.
As I said, DietPi does not control ports in real time. We set a certain configuration during installation, that’s it. If someone or something changes the ports afterwards, DietPi itself cannot do anything. This could be a user or the restore of a backup. It is then up to the user who performs the action.
I wouldn’t even say it’s an Octoprint problem. You simply restored a backup from another system where the port was apparently not specified. As a result, the configuration was overwritten.
You simply restored a backup from another system where the port was apparently not specified. As a result, the configuration was overwritten.
I disagree on that. If a system is working on a specific port, and I restore a backup that does not specify what port to run on, I don’t expect a change in port configuration after restoring a backup. My expectations were set by DietPi which mentions Octoprint runs on port 5001, so that is where I expected to find it after restoring a backup.
We at the DietPi site set the port in Octoprint’s own configuration. This is not a DietPi configuration file. It is the original from Octoprint. This is a behavior of the app and how backups of that app work. It has nothing to do with DietPi
But this is how octoprint works. It looks for a port in the config file and if there is no port specified, it uses port 5000. And in your restored config there is no port specified. You changed the port by yourself.