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.
