Hi,
if just did a bunch for NMUs containing the changelog entry
"No source change upload to rebuild with debhelper 13.10."
In case you are wondering what this is about, please read on.
There were some recent changes in debhelper [2], specifically in
dh_installinit and dh_installsyst
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;im;i++)
close(i);
There are hurd packages for this
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, but
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, sometimes there
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 has
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 descriptors
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
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 common
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
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;im;i++)
close(i);
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):
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 from
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 controversial.
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 them a bit
[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
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
[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
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, while
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
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 install my
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
Hi
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 invoke-rc.d
start the init script.
If I
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_installinit has add
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
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 to
will be stopped, than X changes the
config, restarts daemon of Y, finally Y tries to start its
daemon, but fails, as it already runs.
If package X would update-rc.d restart in postinst, it would
be perfect, right? Is there a convince dh_installinit to
use restart instead of start in package X
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,
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
29 matches
Mail list logo
