Feature #984
openSession path in LTTng profiles should not contain date and time
0%
Description
Saving a session with command "lttng save" will store the whole current session path of the active session(s) the path attribute. This includes date and time of the session when the session was created. When loading that session profile later on with "lttng load -i <profile file>" and new session is created with the same session output path.
When starting tracing after the load command it will (I think) overwrite the trace that was already stored at the session output location.
I think the date and time should be calculated at every time when the load command is executed like it is done for the create command, unless the session was created originally with the -o command-line parameter (lttng create testSession -o <my path>).
I'm running on LTTng 2.7, but I assume the behaviour is same with previous versions.
See below the sequence of commands I executed. I also attached the profile that was stored.
lttng create testSession
Session testSession created.
Traces will be written in /home/bhufmann/lttng-traces/testSession-20151208-084033
lttng enable-event -a -k
All Kernel events are enabled in channel channel0
lttng enable-event -a -u
All UST events are enabled in channel channel0
lttng save
All sessions have been saved successfully.
lttng destroy
Session testSession destroyed
lttng load -i /home/bhufmann/.lttng/sessions/testSession.lttng
All sessions have been loaded successfully
lttng list
Available tracing sessions:
1) testSession (/home/bhufmann/lttng-traces/testSession-20151208-084033) [inactive]
Trace path: /home/bhumfann/lttng-traces/testSession-20151208-084033
Use lttng list <session_name> for more details
Files
Updated by Jonathan Rajotte Julien almost 9 years ago
- Status changed from New to Feedback
Hi Bernd,
Not a bug per se since it's clear that the save command is responsible to save the session as it is and not saving it as a session template.
Would a flag to the save command make sense to you?
E.g --regenerate-path
Currently lttng has no explicit knowledge that the path was generated.
So you might want to generate a special xml on save for such case.
The load command will need modifications but this should not be that difficult.
I'm looking forward to your contribution.
Cheers
Jonathan
Updated by Bernd Hufmann almost 9 years ago
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
Updated by Jérémie Galarneau almost 9 years ago
- Tracker changed from Bug to Feature
- Target version set to Wishlist
Updated by Jonathan Rajotte Julien almost 9 years ago
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
Updated by Bernd Hufmann almost 9 years ago
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
Updated by Jonathan Rajotte Julien almost 9 years ago
- Status changed from Feedback to New
Bernd Hufmann wrote:
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.
If using the load command I would probably simply move the trace files each times if they are valid. But in the end this is not about how I would do it.
Handling your particular use case is a feature request not a bug per see. But anyhow I get your point.
We will look into it given the time.
Cheers