[repo-coord] Re: rpm scripts for daemons, advice please

[Axel Thimm]

Hi Bent,

On Mon, Jul 19, 2004 at 09:53:04AM +0200, Bent Terp wrote:
> I'm working on packaging Torque, a batch queue system,

Yes, please!!! :) :) :)

> and have received some feedback I don't agree with.
> 
> >  Don't stop daemons (at least, not when upgrading),
> 
> Is that normal? To keep version X of a daemon running and in memory,
> while version X+1 is on disk?

I assume everybody on this list will have a different opinion ;)

I'd say in general one should assume misoperation of the old daemon
running with "new" support files/folders, so the cleanest method would
be to stop it before the files are blown away, and restart it after
the files have been upgraded and the old one removed (you would have
to save this condition on disk to be able to use it across
scriplets). Especially if the daemon has deinitialization sequences
(like writing queue data back to disk?), or the upgrade requires
migration of state data this is a must.

Second to that an /etc/init.d/daemon condrestart (or similar) in %post
seems good enough. :)

The argument of "don't stop a daemon when upgrading, let the user do
it" is in general wrong. You should have user intervention when
deciding to upgrade the daemon, not when deciding to restart it. Of
course there are exceptions of 

> Would it be wrong to stop the service in %preun, and resume it in %post?
> There will be a short disruption of service while files are being
> replaced, but it sort of makes sense to me that while it is undefined
> which version of files are in place, we don't really want to use them.
> 
> Or should I just leave it running and do either a start or a restart in
> %post?
> 
> I thought the scripts were applied like this:
> 
> rpm --install: %pre, install, %post
> rpm --erase: %preun, erase, %postun
> rpm --upgrade: old %preun, erase, old %postun, new %pre install, new
> %post.
> 
> But this isn't spelled out in explicit detail in the RPM Guide, and
> given my very limited experience, I may well have gotten it all
> upside-down.

This essay is very illuminating:

http://www-106.ibm.com/developerworks/linux/library/l-rpm3.html

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/repo-coord/attachments/20040719/587c2e85/attachment.bin