[lttng-dev] UST app and lttng-tools compatibility

[Francis Giraldeau]

Le 2012-09-29 14:28, Mathieu Desnoyers a écrit :
> * Francis Giraldeau (francis.giraldeau at gmail.com) wrote:
>> Hi,
>>
>> I wanted to share my lttng-ust 2.1 update experience, maybe it will save
>> time for others.
>>
>> I updated lttng-ust recently. After this change, the app would not
>> produce a trace anymore. No error message is displayed by the traced app
>> to indicate that something is wrong. Even when setting LTTNG_DEBUG_UST
>> to the app's environment variable, there is no error message. The debug
>> output suggests that probes are registered and everything is fine, while
>> it's not.
>>
>> By running lttng-sessiond with -vvv --verbose-consumer, I finally got
>> this message:
>>
>> DEBUG2: UST app PID 8112 is not compatible with major version 3
>> (supporting <= 2) [in ust_app_validate_version() at ust-app.c:2633]
>>
>> Updating lttng-tools to 2.1 solved the issue. Seems that it's mandatory
>> to update lttng-tools to support latest lttng-ust. It may be obvious for
>> developers, but it should be clear for users that they must upgrade both.
>>
>> IMHO, It would be nice if the app side log could tell if the
>> session/consumer refused the registration.
> 
> I agree we should do better.
> 
> Regarding lttng-tools, I think changing this DBG2 message to a WARN
> message would help, so sessiond would show the warning, except in the
> case where it is started with "-d".

Excellent idea.

> On the application side, this is a bit tricky. It has no way to find out
> that it has been rejected by the sessiond. The application registers at
> startup, and then the sessiond keeps the connexion active, but flags it
> as incompatible internally. The reason we do that is because we don't
> want the application to retry endlessly.

Could the registration process block until the sessiond returns some
status? I understand that in commercial setup, the application should
not be prevented to start and run normally if tracing is not available
or misconfigured. But for developers, some env var like
"LTTNG_ABORT_ON_ERROR" could help to diagnose this king of problem.

> Moreover, I cannot change the code for the existing 2.0 UST libs, so
> adding a new message is not possible.

Of course! ;)

> One thing we have in mind for 2.2 or 2.3 is to add syslog support within
> the sessiond. This would provide a nice centralized place to look at
> those logs.

I think it would be great. It's a bit less hidden, but certainly address
concerns for production, and still can be used by developers. An error
message is better than no one! ;)

Cheers,

Francis



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4489 bytes
Desc: Signature cryptographique S/MIME
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20120930/cd433cb1/attachment-0001.bin>