Hi, On Mon, Mar 11, 2013 at 10:53:55AM +0100, Roman Haefeli wrote: > On Fri, 2013-03-08 at 14:15 +0100, Dejan Muhamedagic wrote: > > Hi, > > > > On Fri, Mar 08, 2013 at 01:39:27PM +0100, Roman Haefeli wrote: > > > On Fri, 2013-03-08 at 13:28 +0100, Roman Haefeli wrote: > > > > On Fri, 2013-03-08 at 12:02 +0100, Lars Marowsky-Bree wrote: > > > > > On 2013-03-08T11:56:12, Roman Haefeli <reduz...@gmail.com> wrote: > > > > > > > > > > > Googling "TrackedProcTimeoutFunction exportfs" didn't reveal any > > > > > > results, which makes me think we are alone with this specific > > > > > > problem. > > > > > > Is it the RA that hangs or the command 'exportfs' which is executed > > > > > > by > > > > > > this RA? > > > > It is most probably the exportfs program. Unless you hit the > > "rmtab growing indefinitely" issue. > > No, this is with a later version of the RA. > > > > From the log: > > > Mar 8 03:10:54 vicestore1 lrmd: [1550]: WARN: p_exportfs_virtual:stop > > > process (PID 5528) timed out (try 2). Killing with signal SIGKILL (9) > > > > This means that the process didn't leave after being sent the > > TERM signal. I think that KILL takes place five seconds later. > > Was this with the "rmtab problem"? > > I still don't fully understand. Is this lrmd trying to kill the RA or > the process 'exportfs' with given PID?
The former. I thought I already answered that. > > > For me valuable to know is what is lrmd trying to kill here: the process > > > 'exportfs' or the process of the resource agent? > > > > The resource agent instance. > > > > > I mean, is 'exportfs' broken on said machine? > > > > Name resolution taking long perhaps? > > We use IP addresses everywhere, so I assume it's not related to name > resolution. > > What can I do about a broken 'exportfs'? It happens so seldom that I > don't have a chance to deeply investigate the problem to write a proper > bug report. Do you run the latest resource-agents (3.9.5)? Then you can trace the resource agent, like this: primitive r ocf:heartbeat:exportfs \ params ... \ op stop trace_ra=1 The trace files will be generated per call in $HA_VARLIB/trace_ra/<type>/<id>.<action>.<timestamp> HA_VARLIB is usually, I think, /var/lib/heartbeat. Thanks, Dejan > Roman > > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems