The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Peter Wächtler" <pwaechtler@loewe-komp.de>
To: Andreas Dilger <adilger@turbolabs.com>
Cc: Christopher Friesen <cfriesen@nortelnetworks.com>,
	linux-kernel@vger.kernel.org
Subject: Re: logging to NFS-mounted files seems to cause hangs when NFS dies
Date: Thu, 29 Nov 2001 22:08:44 +0100	[thread overview]
Message-ID: <3C06A3DC.F959F464@loewe-komp.de> (raw)
In-Reply-To: <3C065D2F.B45332C6@nortelnetworks.com> <20011129094348.E29249@lynx.no>

Andreas Dilger schrieb:
> 
> On Nov 29, 2001  11:07 -0500, Christopher Friesen wrote:
> > I'm working on an embedded platform and we seem to be having a problem with
> > syslog and logging to NFS-mounted files.
> >
> > We have syslog logging to NFS and also logging to a server on another machine.
> 
> Why not just log to the syslog daemon on another machine.  Logging to NFS
> does not help you in this case.
> 
> > The desired behaviour is that if the NFS server or the net connection conks
> > out, the logs are silently dropped.  (Critical logs are also logged in memory
> > that isn't wiped out on reboot.)
> 
> > The problem we are seeing is that if we lose the network connection or the
> > NFS mount (which immediately causes an attempt to log the problem), it seems
> > that syslog gets stuck in NFS code in the kernel and other stuff can be
> > delayed for a substantial amount of time (many tens of seconds).  Just for
> > kicks we tried logging to ramdisk, and everything works beautifully.
> 
> Well, it seems obvious, doesn't it?  If the network connection is lost, then
> you can't very well write to the Network File System, can you?  One of the
> features of NFS is that if the network dies, or the server is lost, then
> the client does not lose any data that was being written to the NFS mount.
> 
> > Now I'm a bit unclear as to why other processes are being delayed--does anyone
> > have any ideas?  My current theories are that either the nfs client code has a
> > bug, or syslog() calls are somehow blocking if syslogd can't write the file
> > out.  I've just started looking at the syslog code, but its pretty rough going
> > as there are very few comments.
> 
> This is entirely a syslog problem, if you want to do it that way.  The NFS
> code is working as expected, and will not be changed.  You might have to
> multi-thread syslog to get it to do what you want, but in the end you are
> better off just using the network logging feature and write the logs at
> the server directly.
> 

Well, it could use nonblocking IO like it does with named pipes.

When syslogd logs to a named pipe and the reader does not consume the data,
syslogd will not block but discards the messages.

The best way, like you suggested, is logging to a remote syslogd, running
with syslogd -r

  reply	other threads:[~2001-11-29 21:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-29 16:07 logging to NFS-mounted files seems to cause hangs when NFS dies Christopher Friesen
2001-11-29 16:43 ` Andreas Dilger
2001-11-29 21:08   ` Peter Wächtler [this message]
2001-11-29 21:01 ` Peter Wächtler
2001-11-29 22:42 ` Jesse Pollard

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=3C06A3DC.F959F464@loewe-komp.de \
    --to=pwaechtler@loewe-komp.de \
    --cc=adilger@turbolabs.com \
    --cc=cfriesen@nortelnetworks.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