seems <pid> got lost there by cleanup.
Just make sure to run renice -n -19 <pid> and ionice -c 1 -n 0 -p <pid> where is <pid> your octoprint PID.
It just feels like a bad idea to run OS updates while OctoPrint (or mjpg_streamer or whatever else) is running. To me, this feels like hiring a company to remove/replace your carpet during a wedding; somebody's bound to be inconvenienced.
Just to be clear. I agree that upgrades/updates should not happen while a print is actively being printed. That is why I have been asking how one can tell that a print is active from code/shell script. The upgrade/update should ONLY be allowed to run on an idle system that is NOT actively printing. It would be nice if after it ran there was some indication in the GUI if a reboot was necessary.
So in pseudo code...
Check if a print is actively printing..
if so wait until it is done or exit.
else
check if there are update/upgrade that should be installed..
if so set a flag that will not let prints start
run the update/upgrade
check if a reboot is needed if so send a notification to gui
clear flag preventing prints from starting
Bier und Brezel time 
I’m just a user and I don’t have the slightest desire to delve into packages if something stops working due to updates. I already have a bunch of negative experiences with PIO autoupdates when building marlin 2.0. I don’t want to get the same experience here
Sorry to go off-topic, but can you expand on this?
Not much to expand really, it just turned out that a significant portion of support requests for cases of intermittent printer disconnects, unreachable servers and weird behaviour could be traced back to the Pi browning out due to insufficient power supplies, and once those were swapped for something proper the issues encountered by people magically went away.
Making the undervoltage condition visible in the UI and limiting some functions such as updating and plugin installing which caused file system corruption under brownout conditions has noticeably reduced the support overhead caused by this, leaving me more time to concentrate on actual bug fixes, general maintenance and development.
3 Likes
Yes, and unfortunately some (if not most) printer main boards (RAMPS and custom ones based on Arduino Mega at least) pull power from the USB port too, and compound the issue, or cause all kinds of power problems. This is not something average home user can modify or fix other than getting a higher power 5v supply.
wow... that's really dirty... That can break the USB port... that plastic needs to be really thin.
As for running updates, I would just VPN into my network, and ssh to my Rpi's and update them via the shell. I do that once every two weeks.
I suppose I see one would do this via the UI for the sake of convenience, but I do not suggest anyone to expose their systems to Internet at all! I would even remove the default gateway so it cannot go to the internet when when I'm not around for any extended period of time, or just shut them down.
Maybe I'm paranoid...
That might not be a bad feature request, to be honest.
I tried this but I get permissions errors
Yeah iirc they changed something so sudo needs a password in octopi.
I have to ask @foosel or @guysoft what the did so you can revert it.
With a passwordless sudo it should work.
You might want to ls -l /etc/sudoers.d FOR GREAT JUSTICE!!!!111
The clean solution is to explicitly allow the passwordless execution of an update script instead of ripping a hole in the whole privilege separation.
Could be easily achieved by adding a file to /etc/sudoers.d as already pointed out, see also https://github.com/guysoft/OctoPi/blob/a3c7da1f163f22f28674fbc91aea4e1655338438/src/modules/octopi/start_chroot_script#L136
Side note: general password requirement changes were done by modifying /etc/sudoers.d/010_pi-nopasswd
1 Like
The main issue is that we can't really control what raspbian/rpi-foundation are pushing to the distro.
This means that even though we could add a 'update' button that would update the firmware and all the packages in the distro. It has a high change of breaking everything and leaving sad users. We don't truly have a way to guarantee that. This made us not really explore this option.
Also, in some cases major changes in raspbian are introduced which would require a team of people to automate applying all the changes. This is a service not covered the the Rpi foundation neither. If a new Pi comes out, you need to flash a fresh image.
What I think the best approach is to separate the data from the OS. meaning you put all the user files in one place, and when you want to update just take the data to the new OS, similar to what docker does. Then have something like n00bs or a main raspberrypi image server push the images if you have a farm of printers.
1 Like
I think one way of adressing this would be adding a possibility to start a shell with a notifier and acknoledgement if there is a print busy + extra password.
The user could then go in the shell and check for updates themselves without needing to open an extra ssh session.
Because many people don't take time to update their pi's there are some safety-issues now that could be solved that way. But on the other hand implementing this kind of updates from a html-page is also creating some risks.
I'll consider it if you make some kind of PR, but I am not developing this myself. I rather make it easier to switch SD cards and import your settings from an old one.
My two cents. Trying to go to Bullseye from Buster. If you update the os, octoprint dies, you can load a new image and restore a backup and octoprint is back up, BUT if you have a UPS on it and need mail, or anything else such as static IP,etc. Guess what? You are almost back to the beginning. Needs to be a better way.
Thank,
Joe
What you are describing isn't a OctoPi or OctoPrint problem, but a Linux issue in general, specifically Debian based distribution issues (OctoPi is a customized version of Raspberry Pi OS lite, which in tern is based on Debian).
While it is technically possible to upgrade a distribution in place, it's not recommended, especially in cases where the user doesn't even realize what the underlying OS is in the first place, nor how to deal with it WHEN something goes wrong.
You can search (ie. 'Google') for "debian distribution upgrade in place" and similar terms to see how it works and info on why it's not a great idea.
note: that still won't get you the OctoPi specific upgrades, like the new camera streaming setup in 1.0.0.
I have 12 or 13 Debian machines in my house and have updated in place with no issues. Only when I had a desktop did I have an issue. I also have a procedure for myself to clone my machines and get everything working again. Did not like having to do it when redoing the complete image.
Again, I was only putting in my two cents worth. My Octopi is finally up and running. At least one plugin had to be configed and it didn't work till it was uninstalled and reinstalleed and reconfiged. Yes it was working when I did an Octopi backup and wasn't when restored. The OS update here was a pain.