can we detect when all active windows/apps are closed and auto-restart ?

We could definitely detect when all windows are closed (we know that in Chrome)...but we can't really synchronously enforce that and ensure it stays that way when we would initiate the restart. I also don't think we can know that they don't have any background services running (like if they SSH in themselves and are running a background server in that terminal) for if we did a full container restart automatically (rather than just individual services).

We could try to be smarter about it and know which of our services we can safely restart and if we it's not one we are tracking then we just do the restart anyways (so we'd still need all of this built out; but could make it more user friendly so restarts are needed less often).

What will happen if the user waits a while to restart?

@tbuckley things should still work fine; but any updates we've done to the Debian packages that are needed for new functionality won't be available (things like installing .deb files needed an update like this for example because there were permissions changes)...we should of course not make changes that are not backwards compatible so things aren't broken in this state (just new things may not work).

> but we can't really synchronously enforce that and ensure it stays that way when we would initiate the restart

why can't we ?  we have full control over the services that are communicating here.  seems like it wouldn't be *too hard* to add a signal like "halt UI communication with this VM" or something.

> can know that they don't have any background services running (like if they SSH in themselves and are running a background server in that terminal

we can detect whether there are any active programs running as that user.
also, doesn't default systemd behavior run in sessions that automatically kill processes when they logout of ssh ?

you're right that, if they start up a server as root, and it's in active use, we don't have a way of detecting that.

imo we should consider this the uncommon scenario and have things auto-update transparently by default, and add a knob so for the few people who don't want this, they can disable it (and explicitly accept the system admin responsibility).

of course, if we could have our services just restart as needed, that'd be even better/smoother.

i really really don't think having a "restart for updates" nag UI is the wrong approach by default.  it goes against the fundamentals of Chrome/CrOS in that we try to make things work automatically.

> why can't we ?  we have full control over the services that are communicating here.  seems like it wouldn't be *too hard* to add a signal like "halt UI communication with this VM" or something.

Technically yes, we could likely come up with a way of enforcing this properly...but the user may be expecting certain new features to work, but they won't until all the windows are closed until we auto-restart (or they manually restart), so the notification is useful in that sense.

I did forget to put the ability in to disable automatic updates...but can just do that for the next milestone (created a new bug for that).

I will look into this more in an attempt to try to make this as transparent as possible for our services and auto-restart the ones we can...but the default case of notifying the user Crostini needs a restart I think should stay in for something like sommelier. Overall this also isn't too different from the notification users get when ChromeOS itself updates and tells them they should restart to get that update.

the notifications CrOS updates trigger are not popup notifications.  it's a single arrow that shows up in the tray and goes away when the system reboots.  you could do a similar thing where the arrow shows up and then automatically goes away once we transparently reboot things.  that arrow is used for both OS updates and Flash component updates ...

having the feature enabled isn't the same thing as always having it be active.  if i had to see a notification & manually rectify the situation every time an update was pushed (even though i wasn't using any of the Linux features), that'd get annoying real quick.

just look at how the various nag update screens in other OS's are viewed with derision.  search for "<OS> disable update notification"

Per #4 -- if things aren't going to be severely broken without a restart, I'm hesitant to show much UI.

Would you have a concern if we didn't show any UI at all, and just let the user eventually restart? If we do need UI, Sudha and I can work together on something subtle.

I picked through all of our cros debian packages and there's very few things that would be changed in there which would actually require a service restart. Those are things like environment variable changes for services or other modifications to startup scripts. Most of the stuff we have is other linux config changes which take affect immediately when done.  This could change in the future, but doesn't seem that likely...all the binaries are mounted through Termina, so that type of inconsistency doesn't apply here.

At this point I think we can put this on hold for now until we see a real need to implement it since we don't want to add unnecessary UI prompting/notifications.

sgtm, thanks Jeff.

SGTM, thanks!

Closing this since there's nothing to act on here...we can reopen it later if we want.