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 <[email protected]> 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
> [email protected]
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
