On Nov 12, 2007 11:00 PM, Arthur de Jong <[EMAIL PROTECTED]> wrote:
> Anyone have a better way to detect the highest open file descriptor
> (preferably something that also works inside a chroot jail that does not
> have /proc mounted)? NetBSD seems to have fcntl(F_MAXFD) that should do
> the trick,
On Mon, 2007-11-12 at 12:34 -0600, Steve Greenland wrote:
> On 11-Nov-07, 14:25 (CST), Arthur de Jong <[EMAIL PROTECTED]> wrote:
> > This seems to be quite common code (from one of my packages (cvsd),
> > don't know what the original source for this code was):
> >
> > m=sysconf(_SC_OPEN_MAX);
On 11-Nov-07, 14:25 (CST), Arthur de Jong <[EMAIL PROTECTED]> wrote:
>
> This seems to be quite common code (from one of my packages (cvsd),
> don't know what the original source for this code was):
>
> m=sysconf(_SC_OPEN_MAX);
> for (i=0;i close(i);
>
> There are hurd packages for this
Hi
On Sun, 11 Nov 2007 20:31:55 -0700
Tim Spriggs <[EMAIL PROTECTED]> wrote:
> Is there no way of listing open file handles within a process? It seems
> like there should be a better way. If the kernel knows what file handles
> exist (and lsof can get the info) then what's stopping a process fr
Russ Allbery wrote:
Steve Langasek <[EMAIL PROTECTED]> writes:
On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:
This seems to be quite common code (from one of my packages (cvsd),
don't know what the original source for this code was):
m=sysconf(_SC_OP
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:
>> This seems to be quite common code (from one of my packages (cvsd),
>> don't know what the original source for this code was):
>> m=sysconf(_SC_OPEN_MAX);
>> for (i=0;i> close(i
On Sun, Nov 11, 2007 at 09:25:11PM +0100, Arthur de Jong wrote:
> On Sun, 2007-11-11 at 11:04 +0100, Vincent Danjean wrote:
> > When these mechanisms will be ready, a deamon will be unable to close
> > all its file descriptors (unless it closes the whole range of fd
> > (0--2^16 ?) or unless an ap
On Sun, 2007-11-11 at 11:04 +0100, Vincent Danjean wrote:
> When these mechanisms will be ready, a deamon will be unable to close
> all its file descriptors (unless it closes the whole range of fd
> (0--2^16 ?) or unless an application can get a list of its open fds).
This seems to be quite commo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I would agree that no entity should be passing open file
> descriptors off to other processes unless this is deliberate, and in
> that case a proper policy has been written for it.
Okay, I think we're in agreement there. The only open que
Vincent Danjean <[EMAIL PROTECTED]> writes:
> I agree, too. If I remember correctly, there has been discussion in libc
> and/or kernel to be able to open files with random high-numbered file
> descriptors. When these mechanisms will be ready, a deamon will be
> unable to close all its file descrip
Manoj Srivastava wrote:
> On Sat, 10 Nov 2007 23:45:01 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
>> I'd say that passing the open debconf file descriptor to the
>> daemon is wrong regardless of whether the daemon closes it or not.
>
> Yes.
I agree, too. If I remember correctly, there
On Sat, 10 Nov 2007 23:45:01 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Wearing my SELinux hat on, I find that daemons not closing file
>> descriptors when forking children result in a large number of AVC
>> denied messages. Of course, someti
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> On Fri, 09 Nov 2007 10:03:40 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
>> Those file descriptor close loops are somewhat controversial. Not
>> everyone agrees that they're a good idea, and some upstreams will push
>> back on doing it. I find th
On Fri, 09 Nov 2007 10:03:40 -0800, Russ Allbery <[EMAIL PROTECTED]> said:
> Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
>> This might work, but the correct fix is to get the daemon to close
>> all file descriptors when it daemonizes.
> Those file descriptor close loops are somewhat controve
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Russ Allbery]
>> Those file descriptor close loops are somewhat controversial. Not
>> everyone agrees that they're a good idea, and some upstreams will push
>> back on doing it. I find them a bit dubious myself; there are various
>> hacks that,
[Russ Allbery]
> Those file descriptor close loops are somewhat controversial. Not
> everyone agrees that they're a good idea, and some upstreams will
> push back on doing it. I find them a bit dubious myself; there are
> various hacks that, while hacks, come in very handy but are broken
> by da
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> This might work, but the correct fix is to get the daemon to close all
> file descriptors when it daemonizes.
Those file descriptor close loops are somewhat controversial. Not
everyone agrees that they're a good idea, and some upstreams will push
[Sylvain Garcia]
> Thanks all for your answer, It's work.
>
> I have modify my init script with [pathToTheScriptDaemon] 3> /dev/null
This might work, but the correct fix is to get the daemon to close all
file descriptors when it daemonizes.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBS
Russ Allbery wrote:
Sylvain Garcia <[EMAIL PROTECTED]> writes:
Thanks for your anwswer
How verify if the the program start by init script wait an entry on
standard input; because when use init y hand this script work perfectly.
Ah, hm. This may be a different problem, then. Some daemons
Sylvain Garcia <[EMAIL PROTECTED]> writes:
> Thanks for your anwswer
> How verify if the the program start by init script wait an entry on
> standard input; because when use init y hand this script work perfectly.
Ah, hm. This may be a different problem, then. Some daemons don't close
file des
This one time, at band camp, Sylvain Garcia said:
> How verify if the the program start by init script wait an entry on standard
> input; because when use init y hand this script work perfectly.
strace the process - if it is waiting on input, it will be stuck in a
read on an fd. Compare that fd t
On Wed, Nov 07, 2007 at 08:59:00PM +0100, Sylvain Garcia wrote:
> Selon Russ Allbery <[EMAIL PROTECTED]>:
> > Sylvain Garcia <[EMAIL PROTECTED]> writes:
> > > I would like package an application for debian and use dh_installinit
> > > for install init script, but I have problem.
> >
> > > dh_instal
Selon Russ Allbery <[EMAIL PROTECTED]>:
> Sylvain Garcia <[EMAIL PROTECTED]> writes:
>
> > I would like package an application for debian and use dh_installinit
> > for install init script, but I have problem.
>
> > dh_installinit has add installation script at the of postint, but when i
> > want
On Wed, Nov 07, 2007 at 10:33:58AM -0800, Russ Allbery wrote:
> Sounds like a bug in the init script. In particular, it sounds like the
> init script is starting some program that's waiting for input on standard
> input. This would be bad when the init script is run during system boot
> as well.
Sylvain Garcia <[EMAIL PROTECTED]> writes:
> I would like package an application for debian and use dh_installinit
> for install init script, but I have problem.
> dh_installinit has add installation script at the of postint, but when i
> want install my .deb the postinst script take a pause when
Quoting Henrique de Moraes Holschuh <[EMAIL PROTECTED]>:
> File a serious bug against package Y. initscripts have to exit with a
> successfull status if the daemon is already running.
OK. As this package Y is not (yet) part of Debian, I just changed
it: I added --oknodo to start-stop-daemon and
On Sat, 29 Jan 2005, W. Borgert wrote:
> config, restarts daemon of Y, finally Y tries to start its
> daemon, but fails, as it already runs.
File a serious bug against package Y. initscripts have to exit with a
successfull status if the daemon is already running.
--
"One disk to rule them all
27 matches
Mail list logo
