dh_installinit - Debian

This is a discussion on dh_installinit - Debian ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: dh_installinit

  1. dh_installinit

    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 want continu I must make "Ctrl + c"

    i don't uderstand if is bug of use of dh_installinit or un bug in my
    init script

    the end of my postinst script final (after dh_installinit)


    --------------
    # Automatically added by dh_installinit
    if [ -x "/etc/init.d/obm-satellite" ]; then
    update-rc.d obm-satellite defaults >/dev/null
    if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
    invoke-rc.d obm-satellite start || exit $?
    else
    /etc/init.d/obm-satellite start || exit $?
    fi
    fi
    # End automatically added section


    exit 0
    ----------------------

    PS: I use debian SID to build my package and debian Etch to test install

    Thanks

    --
    Sylvain Garcia


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

  2. Re: dh_installinit

    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

  3. Re: dh_installinit

    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-----


  4. Re: dh_installinit

    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

  5. Re: dh_installinit

    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

  6. Re: dh_installinit

    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-----


  7. Re: dh_installinit

    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

  8. Re: dh_installinit

    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

  9. Re: dh_installinit


    [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

  10. Re: dh_installinit

    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

  11. Re: dh_installinit


    [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

  12. Re: dh_installinit

    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

  13. Re: dh_installinit

    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

  14. Re: dh_installinit

    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

  15. Re: dh_installinit

    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

  16. Re: dh_installinit

    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

  17. Re: dh_installinit


    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-----


  18. Re: dh_installinit

    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

  19. Re: dh_installinit

    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

  20. Re: dh_installinit

    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

+ Reply to Thread
Page 1 of 2 1 2 LastLast