Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion Something stronger then kill -9

View parsed - Show only message text

Message-ID: <3DE3C6E2.CEBA9653@sympatico.ca>
From: John-Paul Stewart <jpstew...@sympatico.ca>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.linux.misc
Subject: Re: Something stronger then kill -9
References: <c673867.0211210922.1aabea69@posting.google.com> <slrnatq9ru.phc.avenj@cerberus.localhost> <arjbhk$5eu$1@bob.news.rcn.net> <j5rlra.ucb.ln@freenet.co.uk> <arufj5$j3u$1@omega-3.right.here> <dukvra.m31.ln@freenet.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 38
Date: Tue, 26 Nov 2002 14:09:22 -0500
NNTP-Posting-Host: 65.93.155.5
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1038339001 65.93.155.5 (Tue, 26 Nov 2002 14:30:01 EST)
NNTP-Posting-Date: Tue, 26 Nov 2002 14:30:01 EST
Organization: Bell Sympatico
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!penguin.no.domain!news

spi...@freenet.co.uk wrote:
> 
> rnich...@interaccess.com wrote:
> > In article <j5rlra.ucb...@freenet.co.uk>,  <spi...@freenet.co.uk> wrote:
> > :Morden <newsp...@nowhere.com> wrote:
> > :> I think it's normal for a process to be non-killable when waiting for
> > :> some I/O. If I/O the process's waiting for never happens the process can
> > :> not be killed. Try to find out what the process is waiting for.
> > :> Maybe there's something in /proc that can be used to find that out?
> > :
> > :Shame the process can't timeout when in such a state... locked D processes
> > :should be *eventually* recoverable. No hardware wait should require more
> > :than half an hour.
> 
> > Here's one contrary data point.  An "ERASE" command to a DDS-2 tape
> > drive takes roughly 3 hours to complete.  That's with the "long" bit
> > set, which is what is compiled into the kernel's "st" driver.
> 
> That's the entire action though isn't it? The process isn't in a "D" state
> all that time. It has to be actively erasing the tape for most of it.

I don't think the process is actually "actively erasing the
tape".  It is my understanding that the application simply
sends an "erase" command of some sort to the tape and waits
for it to complete, with the hardware doing the work.

I'm not the one who made the comment about erasing a DDS-2
tape, but I can say this:  on a Travan tape, a seek done
with 'mt fsf 1' remains in state "D" until the seek
completes.  (The application is doing nothing while the
hardware does the seek.)  With ~8GB in a single tar archive,
that could take _hours_ to get there on my Travan drive.

Some hardware does indeed require more than a half hour wait
in "D" state.


J-P Stewart

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google