ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxx>]

On Fri, May 02, 2014 at 05:27:25PM -0400, Tony Espy wrote:

> >>We simply need a supported, maintainable way to disable arbitrary
> >> services.
> >
> >>If you are recommending that we have a conversation with each
> >>individual service upstream, we are willing to do so, but I'd like
> >>some of the init system folks to weigh in with an opinion here too.
> >
> >>[where init system includes both upstart and the future systemd world]
> >
> >The Foundations team is responsible for init, both before and after the
> >systemd transition. :)
> >
> >I have a good deal of sympathy for Ted's position that disabling *arbitrary*
> >services via the custom image is a serious support problem.  I also
> >understand that, since we're in early days here, it's not possible to
> >comprehensively enumerate the individual services that we need to support
> >override interfaces for in order to get the product to market.
> >
> >So I view upstart overrides in the custom image as an escape hatch, that
> >should be used only when all other options to support a more maintainable
> >interface have been explored and rejected (possibly because they can't be
> >landed in time).  And each individual upstart override that's being applied
> >in a custom image should be reviewed (publicly - i.e., here) to make sure
> >the team can support it going forward, so that those custom images don't
> >find themselves broken unexpectedly due to changes to the underlying upstart
> >jobs.

> So a couple of points/questions...

> 1. If as Ted has proposed, we always stick with standard upstart
> jobs and make them smart enough to handle various system
> configurations.  Do we have a supported customization mechanism to
> feed custom environment variables to system upstart scripts?

There would not be a *generic* mechanism for doing so.  But indeed, a
generic mechanism for overriding the environment of upstart scripts would
pose similar problems in terms of long-term maintainability.

> As mentioned in an earlier reply, we use this type of mechanism for
> dynamically loading the correct device-specific ofono RIL plugin,
> and also for determining the number of SIM slots supported by the
> device. The requisite environment variables are current set from
> known properties configured from within the lxc container.

I can see two ways of doing this:

 - modify the ofono job to include a pre-start script that conditionally
   sets an environment variable, using 'initctl set-env', based on the
   presence of the android container; or,
 - provide a standard system job which is 'start on starting ofono' and
   which looks for the android properties, injecting them into the global
   upstart environment with 'initctl set-env -g'.

Both imply shipping the job within the root tarball, but I don't see that
being a big obstacle, assuming there's a standard mapping of the android
properties to the ofono environment that doesn't have to be updated on a
per-device basis.  Would either of these approaches meet your needs here?

> 2. Although this thread originally mentions custom upstart jobs in
> the context of carrier customizations, it should be noted that there
> 22 existing system override jobs defined in our current Touch
> images. These will need to be taken into consideration as part of
> the systemd migration.

Yes; I've long regarded the overrides in the phone images with concern, and
think we should be figuring out how to "upstream" these into the stock
packages so that overrides aren't needed.  This can (and, I believe, should)
be done independent of the move to systemd.

> >And when that happens, the fewer overrides there are in custom images
> >in the field, the better off we all are.  So Alex, for those places where
> >your team is evaluating disabling stock system services, can you please work
> >with the relevant folks to try to support this a different way?

> Any ideas for alternate solutions?  It's not like overrides are a
> secret hidden feature of upstart.  ;)-

These solutions are going to need to be developed on a case-by-case basis. 
That will be more time-consuming, but it's the best way to ensure the
customization and device images are extending the system in ways that we can
support over the long term.

-- 
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@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature