Closed Bug 533528 Opened 10 years ago Closed 10 years ago
If fennec is running, updates cause profile loss
If you have fennec running in the background, and do a application-manager update (eg. apt-get update/upgrade of fennec), fennec isn't killed. This results in your profile being hosed and/or you not being able to start up fennec again. I am using the 1.9.2 nightly channel. Steps to reproduce: 1) install+run fennec using the 192 nightly channel 2) before updating make sure that you have fennec running 3) update using the nightly channel 4) after update notice that fennec doesn't startup.
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing#Utilities_to_Use_in_Maintainer_Scripts has some utilities you might be able to use to check for a running fennec and prompt user to close. We should probably kill a running Fennec if the user tried to ignore the first warning.
maemo-application-running -d app.desktop is probably what we want, but it isn't supported yet! Pretty sad. see: https://stage.maemo.org/svn/maemo/projects/haf/trunk/osso-application-installer/utils/maemo-application-running.c Also, because our file path includes version information in the installation path (e.g. /opt/mozilla/fennec-1.0b6pre/fennec/fennec), and the -x option requires a absolute full path, it probably isn't what we want. instead, we probably just want to do something like: #! /bin/sh set -e # maemo-application-running -d is not implemented # and -x doesn't deal with regexp RUNNING=`ps | grep /opt/mozilla/fennec*/fennec/fennec` if ["$RUNNING"] then exit 1 fi exit 0 However, the real question is what do we want the behavior to be. If we want to let the user know they need to close Fennec before proceeding means a new string.
okay, kill for 1.0, dialog for 1.1 is the path we are taking. the preinst code will look something like: set -e maemo-application-running -x /usr/bin/fennec if [[ $? = 0 ]]; then echo "Fennec is running. Try to quit nicely" /usr/bin/fennec --shutdown & echo "Waiting...." sleep 3 echo "now killing...." pkill -9 fennec fi exit 0
You could wait longer than 3 seconds, in a loop looking for a fennec in the process list, and then kill -9 after some reasonable timeout? 3 seconds seems pretty slim.
yup. probably going to be >10s. going to profile a bit to get the right number after I code up the --shutdown part.
not ideal, first step until dbus stuff lands.
Assignee: nobody → mozbugz
Attachment #416815 - Attachment description: patch v.1 → patch v.1 (this shouldn't land)
Comment on attachment 417040 [details] [diff] [review] patch v.1 >diff --git a/build.mk b/build.mk >+deb: package >+ @$(MAKE) -C mobile/installer deb >+ Too many tabs here >+++ b/installer/debian/fennec.preinst.in >+RUNNING=`ps -ax|grep "fennec"|grep -v grep|wc -l` >+if [ $RUNNING ]; then >+ dbus-send --system --print-reply --type=method_call --dest=mozilla.fennec /mozilla/fennec/request mozilla.fennec.quit > /dev/null >+ RUNNING=`ps -ax|grep "fennec"|grep -v grep|wc -l` >+ if [ $RUNNING = 1 ]; then >+ pkill -9 fennec >+ fi >+fi Hmm should we give the dbus-send a small sleep to allow nsIAppStartup::Quit to complete? r+ with nits
Attachment #417040 - Flags: review?(mark.finkle) → review+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
verified FIXED on build: Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2b5pre) Gecko/20091216 Firefox/3.6b5pre Fennec/1.0b6pre
Status: RESOLVED → VERIFIED
litmus test case 9792 was created for regression testing this bug.
Flags: in-litmus? → in-litmus+
Component: Linux/Maemo → General
OS: All → Linux (embedded)
QA Contact: maemo-linux → general
Hardware: All → ARM
You need to log in before you can comment on or make changes to this bug.