Supported way to require that a service be stopped prior to installing an .rpm package?

[Jeff]

Hello,

My team is building and maintaining a fairly complex software stack that is being packaged
via rpm.  As part of the requirements, the service provided by the .rpm file must be
stopped prior to installation / update of the package.

Is there any supported / recommended way to do this?  Currently the team uses the %pre
section to check if the service is running and fail if so, but this seems a bit ugly.

[Japheth Cleaver]

On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:
>  Hello,
>
>  My team is building and maintaining a fairly complex software stack that is being
> packaged via rpm.  As part of the requirements, the service provided by the .rpm file must
> be stopped prior to installation / update of the package.
>
>  Is there any supported / recommended way to do this?  Currently the team uses the %pre
> section to check if the service is running and fail if so, but this seems a bit ugly.
https://fedoraproject.org/wiki/Packaging:Scriptlets

It seems like this is something that could be done in %pretrans, as well. Alternatively,
depending on the paradigm you're working with, you could give service restart
responsibility to the rpm process itself. This already happens during most daemon updates
anyway, so if it's for your team's internal use, I'd consider saving state in
%pretrans, stopping the service (if running), and starting back up in %posttrans.

On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:

>  Packaging methods should not be used for this requirement. You should
>
>  be using some system automation tools like Ansible or Puppet or Chef 
>  to make that transaction complete smoothly.
>
>  Openshift uses Ansible for their cluster upgrades.
>  
I don't see why this needs to be the case.

Between %pre, %post, %verify, and the newer %*trans functions, along 
with Requires(pre), etc, 'rpm' provides all the tools you need to 
perform modifications of a service using easily-grokkable logic, already 
running as root, and using easily-testable methods.

Edge cases like saving state have best-practice implementations already 
available, and rpm scriptlets already perform this action for many 
services. Meta-packages which perform service control aren't 
particularly groundbreaking.

Regards,

-jc

[Jeff]

>  On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:
>  
>  https://fedoraproject.org/wiki/Packaging:Scriptlets
>  
>  It seems like this is something that could be done in %pretrans, as well. Alternatively,
>  depending on the paradigm you're working with, you could give service restart
>  responsibility to the rpm process itself. This already happens during most daemon
> updates
>  anyway, so if it's for your team's internal use, I'd consider saving state
> in
>  %pretrans, stopping the service (if running), and starting back up in %posttrans.
>  
>  On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:
>  
>  
>  I don't see why this needs to be the case.
>  
>  Between %pre, %post, %verify, and the newer %*trans functions, along 
>  with Requires(pre), etc, 'rpm' provides all the tools you need to 
>  perform modifications of a service using easily-grokkable logic, already 
>  running as root, and using easily-testable methods.
>  
>  Edge cases like saving state have best-practice implementations already 
>  available, and rpm scriptlets already perform this action for many 
>  services. Meta-packages which perform service control aren't 
>  particularly groundbreaking.
>  
>  Regards,
>  
>  -jc 
Thanks for the response!  could you possibly point me to an example of what you're
referencing?

[Japheth Cleaver]

On 10/25/2016 6:13 PM, jhally(a)gmail.com wrote:
> > On 10/25/2016 4:47 PM, jhally(a)gmail.com wrote:
> >
> > https://fedoraproject.org/wiki/Packaging:Scriptlets
> >
> > It seems like this is something that could be done in %pretrans, as well.
> Alternatively,
> > depending on the paradigm you're working with, you could give service restart
> > responsibility to the rpm process itself. This already happens during most daemon
> updates
> > anyway, so if it's for your team's internal use, I'd consider saving
> state in
> > %pretrans, stopping the service (if running), and starting back up in %posttrans.
> >
> > On 10/25/2016 5:10 PM, Subhendu Ghosh wrote:
> >
> >
> > I don't see why this needs to be the case.
> >
> > Between %pre, %post, %verify, and the newer %*trans functions, along
> > with Requires(pre), etc, 'rpm' provides all the tools you need to
> > perform modifications of a service using easily-grokkable logic, already
> > running as root, and using easily-testable methods.
> >
> > Edge cases like saving state have best-practice implementations already
> > available, and rpm scriptlets already perform this action for many
> > services. Meta-packages which perform service control aren't
> > particularly groundbreaking.
> >
> > Regards,
> >
> > -jc
>  Thanks for the response!  could you possibly point me to an example of what you're
> referencing? 
Hmm. Well, it looks like things have moved around a bit on the wiki 
since I last looked them up, but the basic concepts were discussed at:
https://fedoraproject.org/wiki/Packaging:Scriptlets?rd=Packaging:Scriptle...



I do seem to recall actual code examples there, but I don't see it in 
the merged page history.

Essentially, you'd just be doing something like (untested):

%pretrans
# Check if running, if so, be sure to start back up afterwards
rm -f "/tmp/%{name}.upgrade.restart"

/sbin/service %{name} status >/dev/null && touch 
"/tmp/%{name}.upgrade.restart"
/sbin/service %{name} stop >/dev/null 2>&1


%posttrans
if [ -e "/tmp/%{name}.upgrade.restart" ] ; then
    rm -f "/tmp/%{name}.upgrade.restart"
    /sbin/service %{name} start >/dev/null        || :
else
    /sbin/service %{name} condrestart >/dev/null  || :
fi

exit 0


== * ==

This is untested, but adapted from some logic I'd had in some other, 
hairier, %pre/%post scriptlet that had to do some shuffling around of 
directories and symlinks. I've never actually had to use %*trans myself, 
so if %pre is working for you then I'd simply continue using that.

Note that any use of anything other than lua in %pretrans means that 
your RPM can't be installed at initial/anaconda time, since pretrans 
runs way at the beginning of whatever's happening.


Hope that helps,

-jc