Re: Issues when updating running apps?

Thanks for your answer Greg. You were right; even opinion and conjecture=20
are helpful.

Fellow packager Tim Born also kindly shared his experience directly with=20
me (thanks Tim!), and with his permission I'm posting his response to=20
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 update=20
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 ab=
le
>> 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 they
>> take any sort of precaution when updating. Is it really not an issue i=
f
>> 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 see=
ms
> to be overly concerned with this process inside the rpms.  We have some
> 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 script=
s
>> 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 the
> problem of including this inside the RPM is the db authentication metho=
d.
> I believe most apps I've seen require you to install the RPM, and then =
run
> either a schema import or update script.  I've thought about this on my=
 own
> though and have decided that I like the concept of my application being
> 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 the=
n so
> is making schema changes via package managers).  Remember, I haven't tr=
ied
> 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 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 answe=
rs
> for you, but at this point I guess opinion and conjecture is enough sin=
ce
> no one else has commented.
>
> enjoy
>
> -greg
>
> _______________________________________________
> Rpm-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/rpm-list
>  =20