[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-reconfigure calls init.d scripts with start



Dennis Schoen wrote:
> i've a problem with the interchange (formaly known as minivend)
> Package, that i help Stefan Horburg getting packaged.
> 
> dh_installinit adds this rows to interchange.postinst:
> 
> # Automatically added by dh_installinit
> update-rc.d interchange defaults >/dev/null
> /etc/init.d/interchange start
> # End automatically added section
> 
> As far as i've seen dpkg-reconfigure calls the .config script and
> then the .postinst script.
> 
> So there is the problem when i try running dpkg-reconfigure
> everything will work until the postinst is executed and the init
> script will be called with the "start" parameter. It will fail to
> run, when the sever was already running. The changes made in the
> reconfigure will no be applied.
> 
> Has anyone experienced this problem or is there a simple solution i
> just miss.

This would not be a problem if dpkg-reconfigure could just run the
postrm first. Unfortunatly, it currently does not:

  * dpkg-reconfigure: don't run the postrm of the package. Doing so breaks
    things when for example, the package uses dpkg-divert and tries to
    remove diversions in the postrm. This cannot be an isolated problem
    either. This reverses the change made in version 0.2.52, which did not
    say why I added it in the first place.. (suspicion: non-idempotent
    postinst scripts may need the postrm to clean up after them before being
    called again. However, such scripts are broken.)

Since policy does not currently specify what return code an init script
should return if "start" is run and the daemon is already running, a simple
fix would be to detect the daemon is running, and just exit with a warning.
Indeed, policy says:

     The `init.d' scripts should ensure that they will behave sensibly if
     invoked with `start' when the service is already running, or with
     `stop' when it isn't, and that they don't kill unfortunately-named
     user processes.  The best way to achieve this is usually to use
     `start-stop-daemon'.

Indeed, simple scripts that use start-stop-daemon behave this way:

root@gumdrop:/home/joey>false # notice my shell echos out nonzero return codes
+ exit 1
root@gumdrop:/home/joey>/etc/init.d/cron stop 
Stopping periodic command scheduler: cron.
root@gumdrop:/home/joey>/etc/init.d/cron start
Starting periodic command scheduler: cron.
root@gumdrop:/home/joey>/etc/init.d/cron start
Starting periodic command scheduler: cron.
root@gumdrop:/home/joey>/etc/init.d/cron start
Starting periodic command scheduler: cron.

I do wonder what we'll do if we adopt the FHS, which specifies init script 
return codes. I hope that the FHS specifies a special code for "already
running", then an init script can return that and a postinst can just catch
and ignore it.

-- 
see shy jo



Reply to: