LTTng » LTTng-tools

Hi Jonathan

For me the save and load feature is a great feature of LTTng Tools that brings also a lot of value to the Trace Compass integration. The main use case, for this feature, that I see, is, that users can create the same tracing session for their trouble-shooting activities many times. I think it's not practical that the user has to remove previous traces before every execution of the load command. I don't see the point of re-using the same session directory. If you have an use case for that, please let me know.

Now, there of course several ways to fix this issue. Your suggestion to add a command-line option --regenerate-path to the save feature is one way. Alternatively, you could keep the save command as is and change only the load command to generate a new path or not. In both options, I would argue that the path should be regenerated always by default and there should be a flag to keep the location instead. What do you think?

I'm looking forward to your contribution.

I hope you're not suggesting that the fix is only implemented if I do it.

Best Regards
Bernd

Hey Bernd

Bernd Hufmann wrote:

Hi Jonathan

For me the save and load feature is a great feature of LTTng Tools that brings also a lot of value to the Trace Compass integration. The main use case, for this feature, that I see, is, that users can create the same tracing session for their trouble-shooting activities many times. I think it's not practical that the user has to remove previous traces before every execution of the load command. I don't see the point of re-using the same session directory. If you have an use case for that, please let me know.

One of the other use cases is that someone might want to go back to an initial state on reboot/crash. Even with generated name/path.

Now, there of course several ways to fix this issue. Your suggestion to add a command-line option --regenerate-path to the save feature is one way. Alternatively, you could keep the save command as is and change only the load command to generate a new path or not. In both options, I would argue that the path should be regenerated always by default and there should be a flag to keep the location instead. What do you think?

The wanted behaviour is to save the session with the current configuration. The full path (generated or not) is part of the current session configuration. The save/load command do not produce templates it produces reproducible session configurations.

There is nothing preventing TC from doing a folder check/looking for the home environment variable and adding a suffix to the path or even generating one.

Having the load command perform the generation could be a nice addition but it would require that the save command have a flag for generating the corresponding xml file.

I'm looking forward to your contribution.

I hope you're not suggesting that the fix is only implemented if I do it.

I hope you're not suggesting that the feature is only implemented if I do it. :)

Joking apart this is a great opportunity to dig around the code.

Cheers

Best Regards
Bernd

Hi Jonathan

Jonathan Rajotte Julien wrote:

One of the other use cases is that someone might want to go back to an initial state on reboot/crash. Even with generated name/path.

That's a valid use case. But still, the main use case is trouble-shooting as it is even advertised in the LTTng documentation of LTTng.org (http://lttng.org/docs/#doc-saving-loading-tracing-session).

Now, there of course several ways to fix this issue. Your suggestion to add a command-line option --regenerate-path to the save feature is one way. Alternatively, you could keep the save command as is and change only the load command to generate a new path or not. In both options, I would argue that the path should be regenerated always by default and there should be a flag to keep the location instead. What do you think?

The wanted behaviour is to save the session with the current configuration. The full path (generated or not) is part of the current session configuration. The save/load command do not produce templates it produces reproducible session configurations.

There is nothing preventing TC from doing a folder check/looking for the home environment variable and adding a suffix to the path or even generating one.

That won't work because the path is stored in the XML. The main problem is that the trace is written to the same directory on the system being traced (channel files are even appended). Importing a trace from the system being trace to Trace Compass is not a big issue because name conflicts are already handled (e.g. overwrite or change names).

During trouble-shooting, you wouldn't repeatedly create a session with "lttng create mysession -o /tmp/mytrace", instead you would use lttng "create mysession" to have separate trace pathes, would you? I think this a bug and not a feature.

Having the load command perform the generation could be a nice addition but it would require that the save command have a flag for generating the corresponding xml file.

I'm looking forward to your contribution.

I hope you're not suggesting that the fix is only implemented if I do it.

I hope you're not suggesting that the feature is only implemented if I do it. :)

I'd love to do some C code again but I don't really have time for it. It would be great if this bug could be fixed on your company's side. It would take much less time.

Joking apart this is a great opportunity to dig around the code.

Cheers

Best Regards
Bernd

Best Regards
Bernd