<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: cmresmond/cmcheckdisk problem in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106084#M7537</link>
    <description>I suppose you have already done this, but did you try this with more a higher trace level&lt;BR /&gt;&lt;BR /&gt;devfsd -t &lt;BR /&gt;&lt;BR /&gt;I have had a look at man devfsd and that also talks of variable in bash env &lt;BR /&gt;&lt;BR /&gt;Just trying to help&lt;BR /&gt;&lt;BR /&gt;J-P&lt;BR /&gt;</description>
    <pubDate>Thu, 30 Oct 2003 09:34:02 GMT</pubDate>
    <dc:creator>Huc_1</dc:creator>
    <dc:date>2003-10-30T09:34:02Z</dc:date>
    <item>
      <title>cmresmond/cmcheckdisk problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106081#M7534</link>
      <description>Hi,&lt;BR /&gt;we have the following setup: MC Service/Guard for Linux v.A 11.14.02 on 2 RedHat 7.3 nodes with kernel 2.4.22 and devfs.&lt;BR /&gt;The cmcheckdisk program, spawned by cmresmond at every x seconds aborts with a core dump.&lt;BR /&gt;Running cmcheckdisk alone, it seems that the environment affects it: some times unsetting some env variables fixes the problem; the strange thing is that the name of the variables doesn't matter, only the number of characters.&lt;BR /&gt;&lt;BR /&gt;We believe that it's because the device names in /proc/partitions are long (e.g. 34 chars) and maybe some internal buffer overflows.&lt;BR /&gt;&lt;BR /&gt;Has anyone seen this behaviour?&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 30 Oct 2003 03:49:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106081#M7534</guid>
      <dc:creator>Virgil Chereches_2</dc:creator>
      <dc:date>2003-10-30T03:49:49Z</dc:date>
    </item>
    <item>
      <title>Re: cmresmond/cmcheckdisk problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106082#M7535</link>
      <description>As no one seems to be answering this one I will have a go !&lt;BR /&gt;&lt;BR /&gt;One way I use to find out more about such problem is perhaps, a little twisted, but her goes !&lt;BR /&gt;&lt;BR /&gt;I would try to invoke the faulty command using something like the following ex:&lt;BR /&gt;&lt;BR /&gt;#strace -o test.dat df&lt;BR /&gt;&lt;BR /&gt;this show you all system calls for command df and place result in test.dat, you can then read/analyse test.dat and try/see if you can more informations out of this.&lt;BR /&gt;&lt;BR /&gt;I also sometimes use lsof command to further help me find out more info to continue solution search ...&lt;BR /&gt;&lt;BR /&gt;In your case could try this before and after changing variable and see/check where that leads...&lt;BR /&gt;&lt;BR /&gt;Just Hoping this will toggle/trigger some advance and get you on the way.&lt;BR /&gt;&lt;BR /&gt;J-P</description>
      <pubDate>Thu, 30 Oct 2003 09:11:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106082#M7535</guid>
      <dc:creator>Huc_1</dc:creator>
      <dc:date>2003-10-30T09:11:03Z</dc:date>
    </item>
    <item>
      <title>Re: cmresmond/cmcheckdisk problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106083#M7536</link>
      <description>Hello,&lt;BR /&gt;&lt;BR /&gt;We already did that - indeed, strace+lsof are the first debugging tools. But the problem is that it crashes somewhere in userspace, and gdb shows (on the core) that it SEGFAULT-ed somewhere in glibc/vprintf, which led me to the ideea that it is somehow related to (for example):&lt;BR /&gt; char devname[16];&lt;BR /&gt; sprintf(devname, "/dev/%s", whatever);&lt;BR /&gt;In our case, device names are longer than in non-devfs case, which possibly triggers this. Before switching to devfs, it was ok.</description>
      <pubDate>Thu, 30 Oct 2003 09:20:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106083#M7536</guid>
      <dc:creator>Virgil Chereches_2</dc:creator>
      <dc:date>2003-10-30T09:20:35Z</dc:date>
    </item>
    <item>
      <title>Re: cmresmond/cmcheckdisk problem</title>
      <link>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106084#M7537</link>
      <description>I suppose you have already done this, but did you try this with more a higher trace level&lt;BR /&gt;&lt;BR /&gt;devfsd -t &lt;BR /&gt;&lt;BR /&gt;I have had a look at man devfsd and that also talks of variable in bash env &lt;BR /&gt;&lt;BR /&gt;Just trying to help&lt;BR /&gt;&lt;BR /&gt;J-P&lt;BR /&gt;</description>
      <pubDate>Thu, 30 Oct 2003 09:34:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/cmresmond-cmcheckdisk-problem/m-p/3106084#M7537</guid>
      <dc:creator>Huc_1</dc:creator>
      <dc:date>2003-10-30T09:34:02Z</dc:date>
    </item>
  </channel>
</rss>

