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