mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "schönfeld / in-medias-res" <schoenfeld@in-medias-res.com>
To: linux-kernel@vger.kernel.org
Subject: Re: ncpfs: Connection invalid / Input-/Output Errors
Date: Fri, 09 Sep 2005 09:36:30 +0200	[thread overview]
Message-ID: <43213B7E.9050207@in-medias-res.com> (raw)
In-Reply-To: <431F143F.2070904@vc.cvut.cz>

Hi Petr,

Petr Vandrovec schrieb:
> Enable displaying of connection watchdog logouts on the server.  Do not
> use 'intr' mount option.  Do not send KILL signal to the connection
> which is waiting for reply from server.  If you are not sure that your
> network infrastructure is fine, use 'hard' mount option to disable
> timeouts altogether.

well, the thing with KILL signals is something i found after reading
your email. You did write that to another person a while ago. Now i
found that i missed a thing when i looked for differences between the two
server and got a suspicion on my mind. The only real difference between
the two servers is that the one with the problems does run a nagios nrpe
server and some plugins, e.g. to check disk space on the novell disk,
while the other server does not. Now i found that heavy operations on
the filesystem (e.g. stat'ing many small files in a short time) is a
kind of problematic, if you want to do anything else on the filesystem
at the same time. The second process just hangs until the first one
accessing the ncp filesystem is ready with its operation. Well if
nagios pretends to run a check it does send a request to the nrpe
server, which will start a plugin to check what it has to check.
Now the problem is, that the plugin will not return a result until
the timeout (i'm quiet sure that one exists) exceeds. The only
question now is: Does NRPE Server send a SIGKILL to the plugin when time
out exceeds? I'll try that. Maybe the dog lies buried there.

For now: Thanks for your help. I'll try that first and then eventually
the printk-thing.

> Into 'ncp_invalidate_conn()', or better, into its callers.  One is in
> __abort_ncp_connection (invoked for IPX connections when
> __ncpdgram_timeout_proc fires), second is in ncp_do_request (if server
> reports some problem, or if KILL signal is sent to the process).

Ok, thanks.

Greets
Patrick

  reply	other threads:[~2005-09-09  7:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S932080AbVIGI45/20050907085657Z+286@vger.kernel.org>
2005-09-07 11:08 ` schönfeld / in-medias-res
2005-09-07 12:11   ` Anton Altaparmakov
2005-09-07 14:14     ` schönfeld / in-medias-res
2005-09-07 16:24       ` Petr Vandrovec
2005-09-09  7:36         ` schönfeld / in-medias-res [this message]
2005-09-09 10:46           ` Petr Vandrovec
2005-09-09 11:16             ` schönfeld / in-medias-res

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43213B7E.9050207@in-medias-res.com \
    --to=schoenfeld@in-medias-res.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome