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 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
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
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 s
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
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
daemon of package Y 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" i
30 matches
Mail list logo
