Sylvain Garcia 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 invoke-rc.d
> start the init script.

> If I want continu I must make "Ctrl + c"

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.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.

If the package is using Debconf it may also be a bug in the application.
Debconf uses a file descriptor to communicate with the package scripts
and only exits when the file descriptor is closed. If something
daemonises without closing all file descriptors it doesn't need (usually
all file descriptors that were open when it was invoked) then it will
hold the Debconf file descriptor open, causing Debconf to wait
indefinitely.

--
"You grabbed my hand and we fell into it, like a daydream - or a fever."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQCVAwUBRzIVWQ2erOLNe+68AQKzegP8CoWXWQn728pQehNYFV JHlDCRyDM5MY4R
v7DYySiuwHUcmdjz1Je9fKBOEdxzH1lQEKgE9mqxX2vPIwzvuY NqHovkCRkCUhom
3zNA9xR5TLQcFeY0VZoYwGfOoWJ/i7o6qXsF4OqoQJoNTyTxTP2NXk+/GB49trPw
T2i1b8bLmPg=
=fvr0
-----END PGP SIGNATURE-----

Selon Russ Allbery :

> Sylvain Garcia 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 invoke-rc.d
> > start the init script.
>
> > If I want continu I must make "Ctrl + c"
>
> 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.
>
> --
> Russ Allbery (rra@debian.org)
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>

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.

for the init script I use /etc/init.d/skeleton. When I comeback at my job I will
send my init script.

thanks

--
Sylvain Garcia


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Nov 07, 2007 at 08:59:00PM +0100, Sylvain Garcia wrote:
> Selon Russ Allbery :
> > Sylvain Garcia 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 invoke-rc.d
> > > start the init script.
> >
> > > If I want continu I must make "Ctrl + c"
> >
> > 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.
> >
> 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.

When the script has run and hung, is the process started by the script
running? Then you can get its pid, check in /proc//fd and see what
file descriptors are open.


Hamish
--
Hamish Moffatt VK3SB


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 the list /proc/$pid/fd - it will
likely just be stdin.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHMl3PSYIMHOpZA44RAhX+AJ92WJFJJ4hyURAUw4NDht i5uFYZrQCdGNGR
Z2OsccAWloK60TrXNZfXetg=
=U1/A
-----END PGP SIGNATURE-----

Sylvain Garcia 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 descriptors, and Debian maintainer scripts sometimes have other file
descriptors open. This can create a situation where the maintainer script
waits for the daemon to close the file descriptor and hence hangs.

Often adding:

# Make sure we don't leave file descriptors open.
exec 3>/dev/null
exec
to the start of the init script will fix this problem. That's kind of a
hack, but without modifying the daemon, I'm not aware of a better fix.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russ Allbery wrote:
> Sylvain Garcia 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 descriptors, and Debian maintainer scripts sometimes have other file
> descriptors open. This can create a situation where the maintainer script
> waits for the daemon to close the file descriptor and hence hangs.
>
> Often adding:
>
> # Make sure we don't leave file descriptors open.
> exec 3>/dev/null
> exec >
> to the start of the init script will fix this problem. That's kind of a
> hack, but without modifying the daemon, I'm not aware of a better fix.
>

Thanks all for your answer, It's work.

I have modify my init script with [pathToTheScriptDaemon] 3> /dev/null


Thanks;


--
Sylvain Garcia


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[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 UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Petter Reinholdtsen 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
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 daemons that
do this. (Process-inherited Kerberos caches, for example.)

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[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 daemons that do this. (Process-inherited Kerberos caches, for
> example.)

Oh. I was not aware that some found such feature controversial. Why
can't these people use environment variables to inherit information
between processes? It is ment to be inherited also by daemons, and I
do not believe there is any controversial about that.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Petter Reinholdtsen 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 hacks, come in very handy but are broken by daemons
>> that do this. (Process-inherited Kerberos caches, for example.)

> Oh. I was not aware that some found such feature controversial. Why
> can't these people use environment variables to inherit information
> between processes? It is ment to be inherited also by daemons, and I
> do not believe there is any controversial about that.

Well, to give one example (the Kerberos ticket cache hack), the idea is
that you want somewhat tighter control over what can read the ticket cache
than just per-UID controls. So instead, you store the ticket cache in an
unlinked file with an open file descriptor that's inherited across forks,
and then add the new ticket cache implementation to the Kerberos library
(so the daemon may not be aware it even exists). I think the actual
implementation may do something a bit more complex than an unlinked file.
There's no way to do this with just an environment variable because one
can't put the whole cache in the variable so there's some external object
somewhere that still has to store the cache. (Plus, environment variables
are public.) Without file descriptor inheritance, you have to resort to
things like shared memory segments, which get a lot more annoying.

There are still ways to steal the ticket cache if you have the same UID
but no access to the file descriptor, but it's a lot harder and adds a
moderately useful barrier that has made practical improvements in the
incidence of cache stealing at some sites.

As I say, it's definitely a hack, but this sort of hack is sometimes
useful in various real-world circumstances, at least temporarily. I don't
know of any use of extra file descriptors that I wouldn't call a hack, but
I know of several of these kinds of hacks. (For example, a cheap way of
arranging to be signaled when a daemon exits, even if it puts itself into
a separate process group, is to leave open a high-numbered file descriptor
and then select and wait for EOF on it.)

I guess I lean towards having the system opening the additional file
descriptor be responsible for managing it and controlling its inheritance.
That means closing the debconf file descriptor in init scripts or some
other similar place rather than expecting daemons to be able to handle it,
although I can also definitely see the arguments in favor of daemons
closing file descriptors. (I do think daemons should do something
appropriate with stdin, stdout, and stderr.)

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Manoj Srivastava writes:
> On Fri, 09 Nov 2007 10:03:40 -0800, Russ Allbery 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 dubious myself; there are various
>> hacks that, while hacks, come in very handy but are broken by daemons
>> that do this. (Process-inherited Kerberos caches, for example.)

> 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 are legitimate reasons for
> not closing the descriptors (and these use cases can then be explicitly
> allowed in the security policy). Most cases, though, it seems like the
> authors are just being lazy.

>From a security standpoint, isn't it clearly better to manage the file
descriptors before invoking the daemon rather than just handing them all
off to the daemon and trusting the daemon to close them? Insofar as there
is any security impact here (which is dubious in most cases), I'd say that
passing the open debconf file descriptor to the daemon is wrong regardless
of whether the daemon closes it or not.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Manoj Srivastava wrote:
> On Sat, 10 Nov 2007 23:45:01 -0800, Russ Allbery 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 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 (unless it closes the whole range of fd (0--2^16 ?) or unless an
application can get a list of its open fds).

Vincent


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Vincent Danjean 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 (unless it closes the whole
> range of fd (0--2^16 ?) or unless an application can get a list of its
> open fds).

Yeah, I believe this problem may already exist on the Hurd, which tries to
avoid any set limits on things like file descriptors. That's another
reason why I'm not fond of these close loops.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Manoj Srivastava 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 question is what a
daemon should do when it's mistakenly and erroneously handed open file
descriptors by its parent process that it's not aware of (other than 0, 1,
and 2, of course). Right now, some daemons close all file descriptors up
to some arbitrary point (255 is common) but leave higher ones open, others
try to get the file descriptor limit via getrlimit and close everything up
to that limit, and others only deal with file descriptors they themselves
opened.

(I certainly agree that any daemon that opens file descriptors needs to
handle them appropriately if it also forks -- and, of course, any daemon
that uses PAM may fork. Usually by setting close-on-exec on all opened
file descriptors.)

>> Insofar as there is any security impact here (which is dubious in most
>> cases),

> Why do you say that? If a process acquires a file handle on a
> privileged file while running as dpkg_t; and passes it to debconf
> running as debconf_t; why is there no security impact? dpkg_t might
> have more access than debconf_t in the policy being run.

Well, I was thinking of the specific case that started this discussion,
which as I understand it was the case of a debconf handle being left open
when starting a daemon. I could be misunderstanding the problem, but if
not, while this is a violation, I have a hard time figuring out what a
process could do with the debconf handle. But that may just be lack of
imagination on my part.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 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 package so that should also work.

--
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHN2UnVYan35+NCKcRAhSbAKCWXdGePFL7b+wl1rdHJ+ vYzZcy8wCfaZWv
A5pk7pFPT/TKprifisr3bro=
=mQQ8
-----END PGP SIGNATURE-----

Steve Langasek 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);

>> There are hurd packages for this package so that should also work.

> I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
> useful on Hurd at runtime.

Plus, I suppose making 65,000 pointless system calls during the startup of
a daemon (not a particularly surprising value for the limit on open file
descriptors) isn't really that big of a deal, but it feels kind of "ugh"
to me. If every daemon does that, I wonder if it would have a noticable
impact on startup speed. Probably not, since in Linux system calls are
pretty fast, but that's a large multiplicative factor.

--
Russ Allbery (rra@debian.org)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 application can get a list of its open fds).

> 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 package so that should also work.

I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
useful on Hurd at runtime.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Russ Allbery wrote:
> Steve Langasek 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);
>>>
>
>
>>> There are hurd packages for this package so that should also work.
>>>
>
>
>> I wouldn't be so quick to assume that sysconf(_SC_OPEN_MAX) does anything
>> useful on Hurd at runtime.
>>
>
> Plus, I suppose making 65,000 pointless system calls during the startup of
> a daemon (not a particularly surprising value for the limit on open file
> descriptors) isn't really that big of a deal, but it feels kind of "ugh"
> to me. If every daemon does that, I wonder if it would have a noticable
> impact on startup speed. Probably not, since in Linux system calls are
> pretty fast, but that's a large multiplicative factor.
>

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
accessing that information directly? Maybe it's just not portable enough?


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org