@jneilliii I am confused, what issue do you mean?
You can configure your own update checks and routines in the bundled software update plugin, either from a plugin or via config.yaml. Having something check if there are new Debian packages and then notifying you about that could be done, as could triggering that from OctoPrint's UI and seeing the output.
But something like that definitely doesn't belong into OctoPrint's core (OctoPrint ain't OctoPi), I'm already crossing a line there with the pi support plugin, and I only did that because I just had to find a way to warn people about their crappy PSUs and the problems they cause due to undervoltage.
1 Like
... yeah, and device was not even on Internet 
.. but to be fair, I probbly left original passwords so it's kinda my fault
debian and thus raspbian includes a package "unattended-upgrades", made to do this job. I don't see any reason to leave it to octoprint to do this.
"unattended-upgrades" seems like a good fit as it would send an email to you as to what was upgraded. What is the "approved" way to know if a printer is actively printing? I still feel that we don't want to do this while a print is happening.
whatever files that are open, stay open and readable as long as the process is running, even if the file (as in library) is removed in case of an upgrade. Linux is really neat on this. With this in mind, it should be pretty damn hard for an upgrade to break even a running print unless you have configured unattended-upgrades to automatically reboot for you, which wouldn't be wise.
An unattended upgrade could steal some resources that are needed to push GCODE as fast as possible to the printer.
Should be possible to set APT::Periodic::Unattended-Upgrade "1"; in /etc/apt/apt.conf.d/02periodic on print start, and reset to the original value on finish/cancellation from a (setuid) shell script called either through an event handler or a full blown plugin.
An unattended upgrade could steal some resources that are needed to push GCODE as fast as possible to the printer.
Just make sure to run renice -n -19 and ionice -c 1 -n 0 -p where is your octoprint PID. Also, use nice/ionice in the systemd script when starting the service. With these, it should be no way a normally working system should slow down the process because of a simple upgrade.
1 Like
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