[RFC] Event prefixing policy

Thu Feb 14 02:27:16 UTC 2013

On 02/13/2013 04:45 PM, Steve Langasek wrote:
> On Tue, Feb 12, 2013 at 02:42:43PM -0500, Stéphane Graber wrote:
> 
>>>>> (1) Require session jobs to specify the ':sys:' prefix to react to system
>>>>> events (no prefix or ':user:' would therefore match user events).
> 
>>>>>   start on :sys:foo  # start if 'foo' event emitted at PID 1 level.
>>>>>   start on foo       # start if 'foo' event emitted at Session Init level.
>>>>>   start on :user:foo # start if 'foo' event emitted at Session Init level.
> 
>>>> Option 2 is certainly my preference in terms of semantics, though it may
>>>> make the implementation hairier than we might like (since the session init
>>>> then has to treat the bridged events specially, by *not* adding a prefix to
>>>> their names).
> 
>> I personally prefer Option 1 as it's actually what we have currently in
>> trunk and doesn't require any explicit change to upstart as it's the
>> bridge which currently prefixes the events.
> 
>> I only worked a bit on user jobs at this point, but I don't expect we'll
>> be using :sys: all that much, so having to prefix everything with :user:
>> as we'd have to for Option 2 seems like a bit of a pain for no obvious gain.
> 
> Ok - it sounds like I'm outnumbered two to one, so I'm happy to go along
> with option 1 here.  Indeed, upon reflection I realize that architecturally
> this is WAY simpler to implement in upstart (it only requires changing the
> bridge, not upstart itself), so gets bonus KISS points.
> 
> Indeed, I think lp:~jamesodhunt/upstart/event-prefixes should be tweaked to
> not modify the upstart code at all, because there's no reason we need to
> have a policy here.  We don't really need to prevent someone using : in
> their event names... even if someone wanted to locally emit an event called
> ':sys:started JOB=[...]', that should be allowed as it's useful for
> debugging.  James, what do you think?

Yeah, I think it's best to just treat the forwarded events as standard
events and not try to special case the :sys: prefix anywhere in upstart.
Being able to manually emit those is actually pretty useful for debugging.

>>> My current branch does indeed favour option 1 since:
> 
>>> - it's less surprising I think that no prefix means 'my current
>>>   namespace'.
>>> - the ':sys:' prefix is explicit and even if you haven't read the man
>>>   pages hints that its referencing something out of the ordinary
>>>   (outside the current namespace).
> 
>>> To some extent, I think we should consider the relative proportion of
>>> user jobs that we envisage would need to reference system events.  As a
>>> data point, Stéphanes branch of planned default user jobs currently
>>> doesn't (need to) make any mention of system events but certainly makes
>>> use of user events.
> 
>> Actually, I'll have to for one of the jobs, the event bridge itself
>> should only start if the system bus is available, so I'll need a "start
>> on started :sys:dbus" and have something that sends me that event as
>> it'll have been emitted long before we start the user session.
> 
> Somewhat to the side of the topic, but wouldn't it be saner to just assume
> dbus is running at the time the user session starts?  I'm not sure it's
> possible in practice for this to not be the case, and if it is possible,
> maybe we should fix that instead.

In the current state of the world, I don't think we can get lightdm to
work without dbus, so the only case where it'd be possible would be if
someone ran a system without the system bus and manually started an X
session with a good old startx.

I agree that we shouldn't care about that case at all :)

Another case however which to me feels slightly more interesting is the
possibility of upgrading dbus at runtime. In such case, the bus would go
down and back up, disconnecting all the clients in the process and so
would require all the jobs to properly restart.

But I see that as a nice to have and I know by experience that most
software using dbus never thought of the possibility of the bus going
away and coming back later (and so they all hope that the system bus
will never crash as you pretty much loose your whole machine if it does...).

So yeah, bottom line, for dbus, it's safe to assume it's there.
There may be other cases that I haven't seen yet where we want to depend
on a system job being running to start a matching user job.
One could do that for nm-applet for example, with a 'start on started
network-manager" and "stop on stopped network-manager", to avoid that
extremely leaky and unstable piece of software from running when NM
isn't running on the machine :)

>>> As an alternative approach, we could introduce a 'match' stanza that would
>>> ensure that, if specified, non-prefixed events would actually match those events
>>> whose prefix is specified by the match stanza. For example, the following 2 user
>>> jobs would be equivalent:
> 
>>> job1.conf:
>>>   # reference 2 system-level events explicitly
>>>   start on :sys:foo and :sys:started bar
> 
>>> job2.conf:
>>>   # reference 2 system-level events implicitly
>>>   match :sys:
>>>   start on foo and started bar
> 
>>> Pros and Cons of adding a 'match' stanza:
> 
>>> + means start/stop on conditions can be identical to system-level
>>> + less visual 'noise' in complex conditions
>>> + user jobs can be promoted to system jobs without change (since 'match :sys:'
>>> would be the default at the system level anyway) [1]
> 
>>> - introducing a new stanza has an impact on stateful re-exec (new support code
>>> and tests required).
> 
>> I don't think it's worth it, adding that stanza means we'll pretty much
>> force our users to read the cookbook to figure out exactly what's going
>> on. While it's a good idea for our users to go read our documentation, I
>> really like the simplicity of most of our jobs, with just a few clear
>> stanzas that pretty much anyone can understand without having any
>> upstart knowledge.
> 
> I agree.  A 'match' stanza would be added complexity for no real gain. 
> Simple rules are better.
> 
> 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: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20130213/2a96c94d/attachment.pgp>