Usage of prctl subreaper in upstart user session

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121210/262fbd0b/attachment.pgp>