Re: Reducing downtime on system critical services
On Mon, Apr 03, 2000 at 08:47:41PM +0200, Josip Rodin wrote:
> On Mon, Apr 03, 2000 at 02:19:43PM -0400, Ben Collins wrote:
> > Actually the best way to do this is for the packages to not stop the
> > daemon in the preinst, and restart it in the postinst. This causes
> > the problem. If you look at apache and openldapd (the two that I know that
> > work right), you will notice that in the postinst (after upgrade) the
> > daemons are restarted. That is the Right Way, IMO, and should be proposed
> > on -policy.
> Recently I saw a bug report about dpkg not being able to replace a file
> because program was being executed at the time of installation ("cannot
> overwrite text file" was the message, IIRC)... is this still an issue?
> If not, perhaps the section 7.2 "Debian claims to be able to update a
> running program; how is this accomplished?" in the Debian FAQ needs to
> be adjusted.
>  http://www.debian.org/doc/FAQ/ch-pkgtools.html#s-updaterunning
> or at any other closer mirror. :)
Sounds like old a.out issues to me. I have had no problems with openldapd
upgrades of this sort. Basically (from my reading of the dpkg code), dpkg
will attempt to write to the file, if it cannot, then it will attempt to
unlink it, then write the new file. The beauty behind this is that when
the file us unlinked (use slapd for this example), then it's inode is
still in use by the system (the running process), so it is not really
deleted from the harddisk, it's just not referenced from the filesystem
itself. Once the process is killed, then the inode is freed.
If this weren't the case, then libc6 upgrades would not be possible
without rebooting (you'll note that the old upgrades to hamm asked you to
reboot your system, the reason was to force the running programs to free
up the old libc5 inode, and start with the upgraded libc5, atleasy I think
it was hamm...can't remember).
This is used quite often in temporary files. Create a temporary file, open
it, unlink it, and continue using it. Once you're done and close the file
descriptor, the inode is automatically freed.
The problem is that right now, start-stop-daemon implicitly checks to make
sure that the inode of the file (/usr/sbin/slapd) matches that of the PID
is about to kill (/proc/<pid>/exe). This makes it impossible to use in
this situation, and I myself have had to hand write "foo=`cat
/var/run/slapd.pid`\nkill -TERM $foo" into my init script. This should be
filed as a bug against start-sto-=p-daemon, but I have not had time to
make a proper fix, so haven't bothered.
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` email@example.com -- firstname.lastname@example.org -- email@example.com '