On Mon, Dec 10, 2012 at 02:30:16PM -0600, Ted Gould wrote: > On Mon, 2012-12-10 at 14:23 -0500, Stéphane Graber wrote: > > Would the above work for you or do you see any potential problem with > > that or think of a better way to deal with the 12.04->14.04 upgrade > > scenario?
> I think so. And to be further more precise, it really is only someone > who upgrades to 14.04, logs out of their session and back in without > rebooting. There are other plausible scenarios here, to wit: - user is halfway through the upgrade; upstart, and desktop packages which depend on user session support, have been unpacked (and possibly even configured), but the kernel package has not; the user experiences a power event / kernel crash; on reboot the system comes up, but is still booted to the old kernel - user is partway through the upgrade when X hangs. they're able to kill the X server and restart it, getting back to the lightdm login screen These are both real-world scenarios that affect a number of users each upgrade, and we should handle them gracefully in Ubuntu. There are a number of ways we could (in theory) decide to handle them: - Require subreaper for user session process supervision, and provide user sessions with reduced capabilities when subreaper is not supported. - Require subreaper for process supervision, and fail hard when it's absent; provide some other facility for finishing the dist-upgrade when the user is no longer able to log in due to the user session failing. - Use subreaper for process supervision; disallow all user jobs in Ubuntu until after the 14.04 release (unlikely to be a popular option ;). - Use something other than subreaper support for user job process supervision. > If there were a critical issue there, I'd rather just make it so someone > can't log back in to a full session until there's a reboot. Seems like > someone would only do this by mistake in almost all situations. As above, rebooting is not guaranteed to fix the user's problem. On Mon, Dec 10, 2012 at 03:35:42PM -0500, Stéphane Graber wrote: > Right, the other reason why I didn't want to make upstart just fail to > start entirely in such case is for people who for whatever reason are > asked to test an older kernel which may not have the feature. I don't think that's a scenario that should drive the design here. I'm pretty sure the kernel team isn't going to ask 14.04 users to test a kernel from 12.04. > Same thing for someone who would run a raring container on a precise > host, although userspace would support the feature in such case, they > kernel won't. So in such case I think it's best to offer a session with > a few restricted features (and have a way to detect it) than just plain > fail. This is at least plausible (along with: running in a chroot; and running in a VM where you don't control the kernel). I don't think it's a requirement per se to support these configurations, but there's a chance that whatever we decide we need for the upgrade scenario addresses this too. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
