https://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912016-03-16T03:02:00ZLTTng bugs repositoryLTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28652016-03-16T03:02:00Zjia fangfang.jia@windriver.com
<ul><li><strong>Copied from</strong> <i><a class="issue tracker-1 status-8 priority-4 priority-default closed" href="/issues/1004">Bug #1004</a>: New trace can't generate in persistent memory file system</i> added</li></ul> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28692016-03-18T21:32:08ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> set to <i>Jonathan Rajotte Julien</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul><p>Hi Jia,</p>
<p>Does the file exists as the error suggests ?</p>
<p>Do you use lttng load and a xml session descriptor?</p>
<p>The main reason to use shm is minimize data loss so not squashing existing files make sense since we do not know if the user have collected them. Depending on your use case there is multiples solutions.</p>
<p>Cheers</p> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28752016-03-21T09:49:06Zjia fangfang.jia@windriver.com
<ul></ul><p>Hi,</p>
<p>yes, we use lttng load and xml session descriptor.</p>
<p>My use case is: <br />The system crashed and then it reboot and set up, after that, I run my application with the same shm-path.<br />I want to the new log of my application can be record into my shm-path file.</p>
<p>I try to open shm-path file with O_APPEND or O_TRUNC, it seems like that my application can overwrite the system crash log.</p>
<p>Could you please give some suggestion ?<br />Or I have to save and delete my crash log manually, and then run my application ?</p>
<p>Thanks</p> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28762016-03-21T16:05:02ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul></ul><p>jia fang wrote:</p>
<blockquote>
<p>Hi,</p>
<p>yes, we use lttng load and xml session descriptor.</p>
</blockquote>
<p>So technically you control were the shm path is located and the trace output and these locations are static.</p>
<p>Could you attach the actual xml files for the load command (make sure to replace any confidential informations by fake ones)?</p>
<p>A list of the used commands would be helpful to.</p>
<blockquote>
<p>My use case is: <br />The system crashed and then it reboot and set up, after that, I run my application with the same shm-path.<br />I want to the new log of my application can be record into my shm-path file.</p>
</blockquote>
<p>If you have a set-up phase I would recommend checking for files presence in the shm path and tar it before starting lttng-sessiond/using lttng. All this automatically. Make sure to also delete the files.</p>
<blockquote>
<p>I try to open shm-path file with O_APPEND or O_TRUNC, it seems like that my application can overwrite the system crash log.</p>
</blockquote>
<p>What is your procedure on a system crash ? Reboot and ignore the shm files or save the shm files for further extraction/analysis?</p>
<blockquote>
<p>Could you please give some suggestion ?<br />Or I have to save and delete my crash log manually, and then run my application ?</p>
</blockquote>
<p>I'm sure you could do this easily automatically on boot.</p>
<blockquote>
<p>Thanks</p>
</blockquote> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28792016-03-22T02:25:54Zjia fangfang.jia@windriver.com
<ul></ul><p>Jonathan Rajotte Julien wrote:</p>
<blockquote>
<p>jia fang wrote:</p>
<blockquote>
<p>Hi,</p>
<p>yes, we use lttng load and xml session descriptor.</p>
</blockquote>
<p>So technically you control were the shm path is located and the trace output and these locations are static.</p>
<p>Could you attach the actual xml files for the load command (make sure to replace any confidential informations by fake ones)?</p>
<p>A list of the used commands would be helpful to.</p>
</blockquote>
<p>Attachment is my xml files</p>
<blockquote>
<blockquote>
<p>My use case is: <br />The system crashed and then it reboot and set up, after that, I run my application with the same shm-path.<br />I want to the new log of my application can be record into my shm-path file.</p>
</blockquote>
<p>If you have a set-up phase I would recommend checking for files presence in the shm path and tar it before starting lttng-sessiond/using lttng. All this automatically. Make sure to also delete the files.</p>
</blockquote>
<p>So the easy way is to save and delete the files during the set-up phase before running application :)</p>
<blockquote><blockquote>
<p>I try to open shm-path file with O_APPEND or O_TRUNC, it seems like that my application can overwrite the system crash log.</p>
</blockquote>
<p>What is your procedure on a system crash ? Reboot and ignore the shm files or save the shm files for further extraction/analysis?</p>
</blockquote>
<p>My crash is "echo c > /proc/sysrq-trigger", and then my system will reboot automatically.<br />I want to reboot and "cp" my shm files but not "mv" (that is to say, I did not delete the shm files during set-up). After that, I run my application and then new log can be written into my shm files.<br />So I choose to use O_APPEND or O_TRUNC to open my shm files.</p>
<p>BTW, I found that even O_APPEND will not append new log to shm files. Both O_APPEND and O_TRUNC overwrite the shm files.</p>
<blockquote>
<blockquote>
<p>Could you please give some suggestion ?<br />Or I have to save and delete my crash log manually, and then run my application ?</p>
</blockquote>
<p>I'm sure you could do this easily automatically on boot.</p>
<blockquote>
<p>Thanks</p>
</blockquote></blockquote> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28802016-03-22T02:27:51Zjia fangfang.jia@windriver.com
<ul><li><strong>File</strong> <a href="/attachments/376">mysession.lttng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/376/mysession.lttng">mysession.lttng</a> added</li></ul> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28812016-03-24T16:34:31ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul></ul><p>jia fang wrote:</p>
<blockquote>
<p>Jonathan Rajotte Julien wrote:</p>
<blockquote>
<p>jia fang wrote:</p>
<blockquote>
<p>Hi,</p>
<p>yes, we use lttng load and xml session descriptor.</p>
</blockquote>
<p>So technically you control were the shm path is located and the trace output and these locations are static.</p>
<p>Could you attach the actual xml files for the load command (make sure to replace any confidential informations by fake ones)?</p>
<p>A list of the used commands would be helpful to.</p>
</blockquote>
<p>Attachment is my xml files</p>
</blockquote>
<p>Looks good to me.</p>
<blockquote><blockquote>
<blockquote>
<p>My use case is: <br />The system crashed and then it reboot and set up, after that, I run my application with the same shm-path.<br />I want to the new log of my application can be record into my shm-path file.</p>
</blockquote>
<p>If you have a set-up phase I would recommend checking for files presence in the shm path and tar it before starting lttng-sessiond/using lttng. All this automatically. Make sure to also delete the files.</p>
</blockquote>
<p>So the easy way is to save and delete the files during the set-up phase before running application :)</p>
</blockquote>
<p>Yes since lttng will not squash existing shm files <strong>by design</strong> since it cannot know if the user have extracted/saved them.</p>
<blockquote><blockquote><blockquote>
<p>I try to open shm-path file with O_APPEND or O_TRUNC, it seems like that my application can overwrite the system crash log.</p>
</blockquote>
<p>What is your procedure on a system crash ? Reboot and ignore the shm files or save the shm files for further extraction/analysis?</p>
</blockquote>
<p>My crash is "echo c > /proc/sysrq-trigger", and then my system will reboot automatically.<br />I want to reboot and "cp" my shm files but not "mv" (that is to say, I did not delete the shm files during set-up). After that, I run my application and then new log can be written into my shm files.<br />So I choose to use O_APPEND or O_TRUNC to open my shm files.</p>
</blockquote>
<p>Why not 'mv'?</p>
<p>Where did you use O_APPEND/O_TRUNC ?</p>
<p>The principal scenario for using shm path would be: <br />1) The target crash<br />2) On set-up you have a script that look for orphan lttng files (in the shm path) and move them to a safe place for further analysis<br />3) Start lttng and tracing</p>
<p>Cheers</p> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28822016-03-29T09:48:29Zjia fangfang.jia@windriver.com
<ul></ul><p>Jonathan Rajotte Julien wrote:</p>
<blockquote>
<p>jia fang wrote:</p>
<blockquote>
<p>Jonathan Rajotte Julien wrote:</p>
<blockquote>
<p>jia fang wrote:</p>
<blockquote>
<p>Hi,</p>
<p>yes, we use lttng load and xml session descriptor.</p>
</blockquote>
<p>So technically you control were the shm path is located and the trace output and these locations are static.</p>
<p>Could you attach the actual xml files for the load command (make sure to replace any confidential informations by fake ones)?</p>
<p>A list of the used commands would be helpful to.</p>
</blockquote>
<p>Attachment is my xml files</p>
</blockquote>
<p>Looks good to me.</p>
<blockquote><blockquote>
<blockquote>
<p>My use case is: <br />The system crashed and then it reboot and set up, after that, I run my application with the same shm-path.<br />I want to the new log of my application can be record into my shm-path file.</p>
</blockquote>
<p>If you have a set-up phase I would recommend checking for files presence in the shm path and tar it before starting lttng-sessiond/using lttng. All this automatically. Make sure to also delete the files.</p>
</blockquote>
<p>So the easy way is to save and delete the files during the set-up phase before running application :)</p>
</blockquote>
<p>Yes since lttng will not squash existing shm files <strong>by design</strong> since it cannot know if the user have extracted/saved them.</p>
<blockquote><blockquote><blockquote>
<p>I try to open shm-path file with O_APPEND or O_TRUNC, it seems like that my application can overwrite the system crash log.</p>
</blockquote>
<p>What is your procedure on a system crash ? Reboot and ignore the shm files or save the shm files for further extraction/analysis?</p>
</blockquote>
<p>My crash is "echo c > /proc/sysrq-trigger", and then my system will reboot automatically.<br />I want to reboot and "cp" my shm files but not "mv" (that is to say, I did not delete the shm files during set-up). After that, I run my application and then new log can be written into my shm files.<br />So I choose to use O_APPEND or O_TRUNC to open my shm files.</p>
</blockquote>
<p>Why not 'mv'?</p>
</blockquote>
<p>Because at that time I did not know I need to 'mv' :)</p>
<blockquote>
<p>Where did you use O_APPEND/O_TRUNC ?</p>
</blockquote>
<p>run_as_open(session->metadata_path...) in lttng-tools/src/bin/lttng-sessiond/ust-registry.c and run_as_open(session->metadata_path...) in lttng-tools/src/common/ust-consumer/ust-consumer.c</p>
<p>Do I misunderstand something ?</p>
<p>BRs</p>
<blockquote>
<p>The principal scenario for using shm path would be: <br />1) The target crash<br />2) On set-up you have a script that look for orphan lttng files (in the shm path) and move them to a safe place for further analysis<br />3) Start lttng and tracing</p>
<p>Cheers</p>
</blockquote> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28832016-03-29T20:04:30ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul></ul><p>Good.</p>
<p>Regarding the O_APPEND/O_TRUNC I would recommend against doing this change for the sake of crash data persistence.</p>
<p>With the change made to the set-up phase are you satisfied with the lttng shm feature and the lttng-crash utility ?</p>
<p>Cheers</p> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28842016-03-31T01:55:02Zjia fangfang.jia@windriver.com
<ul></ul><p>Jonathan Rajotte Julien wrote:</p>
<blockquote>
<p>Good.</p>
<p>Regarding the O_APPEND/O_TRUNC I would recommend against doing this change for the sake of crash data persistence.</p>
</blockquote>
<p>OK, Thank you so much.</p>
<blockquote>
<p>With the change made to the set-up phase are you satisfied with the lttng shm feature and the lttng-crash utility ?</p>
</blockquote>
<p>We will change the set-up phase and other features are fine for us. If any problem, we will update.<br />Thanks again for quick reply :)</p>
<blockquote>
<p>Cheers</p>
</blockquote> LTTng-tools - Bug #1005: New trace can't generate in persistent memory file systemhttps://bugs.lttng.org/issues/1005?journal_id=28872016-04-07T20:28:56ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul>