Usage of prctl subreaper in upstart user session

Tue Dec 11 04:21:19 UTC 2012

On 12/10/2012 08:59 PM, Steve Langasek wrote:
> 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.

That's from my point of view the option that's the easiest to implement
and as the best user experience if something goes wrong.
The only thing we loose is the ability to respawn something that
crashes, but respawning crashing software isn't the main use of upstart
and on most system, it should be a pretty rare occurence, at least
during the window where the user finishes the upgrade by rebooting the
system.

>  - 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.

Certainly trivial to implement, though the effort needed to implement
that would be similar if not bigger than simply implement the
respawn-less mode in case prctl failed.

>  - Use subreaper for process supervision; disallow all user jobs in Ubuntu
>    until after the 14.04 release (unlikely to be a popular option ;).

Pretty unlikely to be popular indeed :)

>  - Use something other than subreaper support for user job process
>    supervision.

That's indeed a possibility. The other options mostly involve a complex
interaction between the user's upstart and pid 1. So not impossible to
do, but way more complex than the one line prctl call and would
introduce its own set of corner cases. The most obvious one coming to
mind, is the impossibility to run upstart in the user session but
something else for pid 1. Granted, that's not a problem for Ubuntu, but
may be one for Debian or any other distro that may be interested in
using upstart for the user session.

>> 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.

So yeah, we need to make sure you can get a working session without the
subreaper, so you can do whatever is needed to fix your system, finish
the upgrade and reboot. But if the only thing we loose is the respawn
capability, then that's really not a problem, because we don't have that
today and our desktop pretty much work anyway.

I doubt we ever want to get to a point where our desktop entirely relies
on upstart being able to respawn crashing software. We should really
just fix the crashes and have upstart be a safety net in case things go
really wrong.

> 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.

Right, I know we're not going to focus on this, but it's something I do
everyday with some of my sparetime work like Edubuntu WebLive, where we
offer full desktop sessions of Edubuntu 12.04 or 12.10, running as
containers on 12.04's 3.2 kernel.
When 13.04 releases, we're pretty likely to still have a few hosts
running the 3.2 kernel, so having some kind of graceful fallback will be
saving me a bunch of testing and kernel upgrades and I doubt I'm the
only one doing similar VDI kind of things on Ubuntu.

> Thanks,
> 

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20121210/0b19f374/attachment-0001.pgp>