ubuntu-phone team mailing list archive

[Tony Espy <espy@xxxxxxxxxxxxx>]

On 05/02/2014 04:37 PM, Steve Langasek wrote:
> On Fri, May 02, 2014 at 10:45:11AM -0700, Alex Chiang wrote:
> > On Fri, May 2, 2014 at 9:15 AM, Ted Gould <ted@xxxxxxxxxx> wrote:
> > > On Fri, 2014-05-02 at 08:38 -0700, Alex Chiang wrote:
> > > > As a real world example of the services we might want to disable:
> > > >
> > > > - mediascanner service
> > > > - urldispatcher
> > > > - mtp-server
>
> > > Hmm, as the upstream for URL Dispatcher that makes me a bit nervous. Why?
>
> > 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?

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.

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.

> As Ted rightly notes, at some point in the future *all* upstart overrides
> are going to break because we're going to stop using upstart as the system
> init.

At minimum, we need to plan a migration path for the known overrides 
mentioned above.

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

> Upstart support for multiple config dirs is still a useful feature which
> we'll try to implement for you, but if it turns out you don't actually need
> it in practice because the number of overrides needed is zero, so much the
> better.

+1 for minimizing their usage.

Regards,
/tony