Baffling Debian installation script: service starts but then quits mysteriously - Why?

Question

I've been struggling with this one for a while and I'm thoroughly baffled.

I have this postinst Debian script that is supposed to start a service once installation (of the service executable) is complete. As best I can tell, the service does start successfully, but it then immediately and mysteriously quits. Restarting the service from the command-line works fine once Synaptic concludes.

I tried writing a dummy package to verify this. The dummy package installs /etc/init/service-dummy.conf and a symbolic link to that file, named /etc/init.d/service-dummy (just like the original service). The contents of service-dummy.conf are the same as service.conf. The dummy starts the service...and then the service keeps on running. So I can't even reproduce my problem!

The postinst script does this:

#!/bin/sh
set -e
case "$1" in
   configure)
    # (instructions which config, make and install the freshly installed source code)
    ldconfig
    echo "Install concluded"
    if [ -e "/etc/init/service-dummy.conf" ]; then
       echo "Starting service-dummy root service" | tee service.log
       service service-dummy restart | tee --append service.log
    else
       echo "service-dummy.conf not installed"
    fi
    echo "Postinst complete"
   ;;
   *)
    echo "postinst called with unknown argument '$1'" >&2
   ;;
esac
# exit 1 to ensure installer stalls
exit 1

Synaptic displays the log:

...
Starting service-dummy root service
stop: Unknown instance:
service-dummy start/running, process 9207
Postinst complete
dpkg: error processing service-dummy (--configure):
 subprocess installed post-installation script returned error exit status 1
...

It's as if upstart needed to be refreshed?

I tried more things and then I did get it to work, sort of: I try starting the service, then abort the script with an exit 1, and when the script runs a second time (postinst, same parameters, so I detect the second run otherwise), I start the service again, and this time it sticks.

A key clue is in the log:

Postinst complete (aborting script)
dpkg: error processing service-dummy (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
 service-dummy
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up service-dummy ...
service-dummy postinst configure
Starting service-dummy a second time
stop: Unknown instance:
service-dummy start/running, process 4034
Postinst complete (aborting script recovery attempt)

So I guess my question now becomes:

How do I force ldconfig to not defer its processing?

Answer 1

Found the right clue here: http://lists.debian.org/debian-glibc/2008/07/msg00169.html

Turns out apt-get temporarily prevents use of ldconfig by replacing it with something else. The solution to my problem is to very simply call ldconfig.real instead of ldconfig in the script.