[systemd-devel] [PATCH] Break JobNew signal dbus signature by adding JobType.

[Lennart Poettering]

On Sun, 11.01.15 18:08, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

> At the moment JobNew and JobRemoved signals are not useful for
> tracking streams of events. JobType is missing from both of them, and
> thus one can only track that "something" is happening and to which
> units (And whether "something" is about to happen, finished, failed,
> got aborted etc.). To get the JobType, one needs to query property
> from the job, however this works only for "slow" jobs, typically the
> job is gone on the systemd side already and thus subscriber has no
> chance in quering the job type.
> 
> It looks like previously JobNew signal api was changed in 2012. Today
> however there are slightly more clients of JobNew/JobRemoved
> signals. Performing the codesearch.debian.net queries, JobRemoved has
> a few users (e.g. go-systemd -> docker.io), but JobNew only has
> systemd-ui as it's consumer. I am proposing to break JobNew signature,
> patch systemd-ui to handle both cases. And then users of JobRemoved
> signal would be able to get job_type, by subscribing to JobNew signal
> and caching/storing the job_type.

This stuff is actually covered by the stability guarantee. Hence I am
very conservative about changing this.

I'd be very careful with adding more and more bits to the existing
signals. I mean, I am sure for lots of cases people would want even
more bits sent along, but where would we say no then?

Sending out JobNew with basic information, and then expecting clients
to query the newly appeared job's properties to get more is an OK
strategy I think. It *is* racy, since by the time the client would
query the properties the job might already be gone again, but at least
this window is smaller than for JobRemoved: if you'd want to learn
more about a job that just finishd, you'd have to query a job object
that well, just disappeared to just have disappeared...

I general, if we really do want to do something about this entire
problem set, then we should go all the way and start adopting David
Zeuthen's ObjectManager stuff, that is even described in the dbus
spec, and for which we have nice support for sd-bus. It's a bit
chatty, but it is race-free and solves this problem comprehensively.

Lennart

-- 
Lennart Poettering, Red Hat