Re: Please stop apps going into state D uninterrupted sleep !!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Tue, 2012-05-08 at 13:16 -0700, Joe Zeff wrote:
> On 05/08/2012 12:39 PM, Patrick O'Callaghan wrote:
> > On Tue, 2012-05-08 at 19:42 +0100, Andrew Gray wrote:
> >> >  Hi
> >> >
> >> >  Either give use a way to kill a hung cp or rsync  when the VPN goes down
> >> >  and they end up is state D uninterrupted sleep or stop apps being able
> >> >  to go into uninterrupted sleep !!
> > It is*not possible*  to kill a process in D state. D state can be
> > defined as "the state which cannot be interrupted".
> 
> I think it's fairly clear that Mr. O'Callaghan knows that.

I think you mean Mr. Gray.

>   He's 
> complaining about the consequences of there being an uninterruptable 
> sleep.  If I read him right, he's saying that it should always be 
> possible for the user to force a hung app to die when it's clear to the 
> user that something has happened that makes it impossible for the app to 
> continue, such as rsync completing when the remote server's known to 
> have crashed.  At this point, probably the best way to proceed is to 
> request that whoever maintains the programs in question modify them so 
> that they don't enter this state when accessing a remote file system or 
> that there's some way to get the app's attention and force it to abort. 
>   On the surface, at least, the request sounds reasonable, although I'll 
> be the first to admit that things like this are often much more 
> difficult than they sound.

As I tried to explain, rewriting a couple of apps is not going to hack
it. The apps don't *know* they're using a networked filesystem, they're
just accessing files. They could find out and try to take measures, but
then what about all the other apps that also write files? Rewrite tar,
cpio, dd, cat, ...?

The price of treating a networked fs as equivalent to a local one is
that you get screwed when it doesn't behave like a local one. Dealing
with this in a coherent and consistent way is hard. See the literature
on distributed filesystems. The semantics of an NFS system are *not* the
same as a local system. We brush this under the carpet most of the time
because it usually works, but sometimes the differences bite.

poc

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org



Photo 4 Less

[Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Find Someone Special]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

Add to Google Powered by Linux