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
next prev parent 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