Re: Issues when updating running apps?

Adrián Márques <[email protected]> Fri, 03 Oct 2008 15:16:17 -0300
Newsgroups gmane.linux.redhat.rpm.general
Message-ID <[email protected]>
Hello there,

I tried my luck with this question at linuxquestions.org and got a=20
couple of answers already.

In case you want to take a look at them:

http://www.linuxquestions.org/questions/linux-general-1/how-to-upgrade-ru=
nning-apps-preferably-through-rpm-673813/

Cheers.

Adri=E1n.

Adri=E1n M=E1rques escribi=F3:
> Thanks for your answer Greg. You were right; even opinion and=20
> conjecture are helpful.
>
> Fellow packager Tim Born also kindly shared his experience directly=20
> with me (thanks Tim!), and with his permission I'm posting his=20
> response to the list in order to share it with everyone else.
>
> Is there anyone else that could provide any input on this?
> As an extra comment, the app in question is not a daemon, it's=20
> user-interactive, so stopping it in the %pre section prior to the=20
> update is not an option for me.
>
> Thanks.
>
> Tim's email:
>
> Hello Adrian -
>
> I'm surprised the RPM for the application being updated does not stop=20
> & restart the service daemon(s) as part of the update.
> That was how I was taught to do things.
>
> I suppose it's possible there are apps out there that can ride over=20
> having their files being changed out from under them.
> Not many of mine can.  So in the %pre we check for an update and stop=20
> the app, then in the %post we again check to see if this is an update=20
> & restart the app.
>
> Works well for us.
>
> best
> -tim
>
> [email protected] escribi=F3:
>>> I apologize for insisting on this matter, but so far I haven't been=20
>>> able
>>> to find info on this anywhere. I've looked at tomcat's and openoffice=
's
>>> spec files as examples of packaged java apps, but it doesn't seem the=
y
>>> take any sort of precaution when updating. Is it really not an issue =
if
>>> the app happens to be running at the time?
>>>    =20
>>
>> In my experience I don't know that I've found a single web app that=20
>> seems
>> to be overly concerned with this process inside the rpms.  We have som=
e
>> internal java web apps, and I believe they just have "turn off x and y
>> services" listed in the update docs we distribute.
>>
>> =20
>>> As for updating a database schema accessed by our app, I suppose we
>>> could add that logic to the app itself and have it check before it
>>> starts whether it should modify the database, but I find adding scrip=
ts
>>> in the RPM much easier and I'd prefer any problems with the
>>> modifications to come up the moment the update is applied and not
>>> whenever the app is next started.
>>>    =20
>>
>> Once again, I haven't seen many that addresses this issue.  Part of th=
e
>> problem of including this inside the RPM is the db authentication=20
>> method.
>> I believe most apps I've seen require you to install the RPM, and=20
>> then run
>> either a schema import or update script.  I've thought about this on=20
>> my own
>> though and have decided that I like the concept of my application bein=
g
>> aware of its own schema, and managing the changes to the db itself (i
>> realize that this can in and of itself be a bit of a nightmare, but=20
>> then so
>> is making schema changes via package managers).  Remember, I haven't=20
>> tried
>> implementing it.
>>
>> =20
>>> I'd really appreciate any comments you could give me on this, whether
>>> they are direct answers, indirect tips on how I could find this=20
>>> info, or
>>> kind advice to go RTFM (as long as you tell me which FM in particular
>>> that would be :) )
>>>    =20
>>
>> I was avoiding commenting on this because I didn't have any solid=20
>> answers
>> for you, but at this point I guess opinion and conjecture is enough=20
>> since
>> no one else has commented.
>>
>> enjoy
>>
>> -greg
>>
>> _______________________________________________
>> Rpm-list mailing list
>> [email protected]
>> https://www.redhat.com/mailman/listinfo/rpm-list
>>  =20
>
> _______________________________________________
> Rpm-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/rpm-list