Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Oct 2002 11:10:04 -0700 (PDT)
From:      Peter Pentchev <roam@ringlet.net>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/43739: cannot open file without obvious reason
Message-ID:  <200210071810.g97IA4Yi093523@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/43739; it has been noted by GNATS.

From: Peter Pentchev <roam@ringlet.net>
To: Arne Woerner <woerner@mediabase-gmbh.de>
Cc: fanf@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/43739: cannot open file without obvious reason
Date: Mon, 7 Oct 2002 20:21:07 +0300

 On Mon, Oct 07, 2002 at 05:07:42PM +0000, Arne Woerner wrote:
 > Wrong! Wrong! Wrong! :)
 > 
 > Due to the "lockf" it is impossible that there are more than
 > two ICanDo.sh processes...
 
 Uhm.. excuse me?  What is to prevent the SSH session starting up
 a billion of ICanDo.sh processes?
 
 Each SSH session operates in one of the following ways:
 
 1. Log in - this eats a file descriptor for the socket.
 
 2. Start a shell running ICanDo.sh - this eats a couple of file
    descriptors for the shell's /bin/sh executable and for the ICanDo.sh
    file that the shell needs to read to execute.
 
 3. Start executing ICanDo.sh - at this point, there are at least two
    file descriptors consumed by this session on the target host.
 
 4. Start lockf(1) - this needs an additional file descriptor for reading
    in the lockf(1)'s executable file.
 
 5. Open the 'gaga' lockfile.
 
 6. Try to flock(2) the 'gaga' lockfile *after having opened it* -
    please take a look at the lockf(1), flock(2) and lockf(3) manual
    pages; the lockfile needs to be opened in order to be locked.
 
 At this step, if the file may not be locked, there are still at least
 two, maybe up to four file descriptors in use, two of which may not
 be reclaimed under any circumstances.  So, each of your billion SSH
 sessions eats up at least two file descriptors.
 
 > I think somebody who is able to find kernel bugs quickly
 > should analyse this problem insteadof fantazising... :)
 
 I think somebody should spend a little more time reading the relevant
 utilities' manual pages :)
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev	roam@ringlet.net	roam@FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 This sentence is false.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210071810.g97IA4Yi093523>