Bug 684207 - "oocalc somefile.xls" doesn't exit when the window is closed
"oocalc somefile.xls" doesn't exit when the window is closed
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-11 08:13 EST by Horst H. von Brand
Modified: 2011-10-21 10:19 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-21 10:19:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2011-03-11 08:13:34 EST
Description of problem:
After updating (and before relogging in) I got an Excel file, and ran "oocalc somefile.xls". For some time now this used to freak me out, as the command exited only to show the window quite a lot later. So I ommited '&' at the end. But when I closed that (only!) open OOo [should that be LOo?!] window, I didn't get the bash prompt back. 'ctrl-Z' and ps(1) show that the program is still running:

$ ps
  PID TTY          TIME CMD
 3579 pts/7    00:00:00 bash
21003 pts/7    00:00:00 soffice
21015 pts/7    00:00:03 scalc.bin
21066 pts/7    00:00:00 ps
$ ps -p 21015 -l
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S   501 21015 21003  0  80   0 - 295429 poll_s pts/7   00:00:03 scalc.bin
$ ps -p 21003 -l
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S   501 21003  3579  0  80   0 - 27081 wait   pts/7    00:00:00 soffice

Version-Release number of selected component (if applicable):
libreoffice-calc-3.3.1.2-6.fc16.x86_64

How reproducible:
Tried just once

Steps to Reproduce:
1. oocalc anything.xls
2. Quit (by X on the upper right corner)
3.
  
Actual results:
Application still running, no window

Expected results:
Quit

Additional info:
Comment 1 Horst H. von Brand 2011-03-11 08:14:29 EST
I believe the Libreoffice Quickstarter showed up only when I started oocalc.
Comment 2 Caolan McNamara 2011-03-11 08:25:55 EST
a) Had no LibreOffice running
b) opened a .xls, it started up with fairly reasonable speed.
c) closed the .xls, LibreOffice shutdown

Is the quickstarter enabled or disabled, I feel like I've asked this question before. See tools->options->memory->enable systray quickstarted, if the quickstarter is enabled then just disable it
Comment 3 Horst H. von Brand 2011-03-14 16:37:39 EDT
(In reply to comment #2)
> a) Had no LibreOffice running

Yep. First time I started someting in LOo. Had just updated LOo (and a lot of other stuff)

> b) opened a .xls, it started up with fairly reasonable speed.

Yes.

> c) closed the .xls, LibreOffice shutdown

Exactly.

> Is the quickstarter enabled or disabled, I feel like I've asked this question
> before. 

Sure did. It was enabled, AFAICT. It is enabled now, no configuration change on my part. (I've rebooted a few times since the last update).

>         See tools->options->memory->enable systray quickstarted, if the
> quickstarter is enabled then just disable it

Just tried again (OK, OK, so I needed to look at an .xls), and it didn't happen again.

As it just happened this single time, I'm assuming it is again a glitch in updating LOo while the quickstarter is running.
Comment 4 Caolan McNamara 2011-03-14 17:41:01 EDT
"I'm assuming it is again a glitch in updating LOo while the quickstarter is running."

What's supposed to happen now, for that specific scenario, is that if the quickstarter is running, and LibreOffice is updated, then through the magic of a gio file monitor on the location of the quickstarter library itself, that the quickstarter automatically exits if the older quickstarter library is moved, deleted or the file system unmounted, or a new one created over it. This is what it does here when I test rpm update with the qs active during an rpm upgrade.

If e.g. some other component e.g. writer was active, and an upgrade done, and then calc launched that might account for it maybe. Or maybe something like calc open, writer opened, calc closed, upgrade while old writer open, impossible to launch new calc libs. 

If I could just nail down the scenario I could try a similar hack to e.g. detect the general case of being upgraded while running and give a dialog on upgrade related epic component launch failure of "upgrade detected, LibreOffice restart required, restart now/later?"
Comment 5 Horst H. von Brand 2011-03-15 08:15:23 EDT
In my case I had rebooted, started oocalc on a file, and meanwhile ran a "yum update" (the actual updating happened while oocalc was running). I did not start any other oo* program before trying to close oocalc.

If this is a case of "updating beneath running `user daemon'", wouldn't that merit a more global solution than a LOo specific hack? Can't the postinstall script take care of sending a HUP signal (legacy daemon style) to running instances to get them to restart? AFAICS the number of "always background running processes" can only increase with the complexity of desktop environments... only *please* don't go the "update and reboot" route Windows style.
Comment 6 Caolan McNamara 2011-03-15 09:00:34 EDT
FWIW the same effect exists in firefox where after an upgrade when running the search engine bar doesn't work anymore.

Sending things hup won't really work unless they know what to do under that circumstance, some form of dbus listen for app_reinstalled event might be nice. But fundamentally you're kind of screwed as a non-trivial app which may dlopen components at any time during your life-cycle if you're running and something updates your libs from out from under you unless super strict adherence to ABI compatibility is stuck to for each and every update. 

As a trivial app you generally have loaded in everything you'll need for your lifetime, so deleting/moving them doesn't affect you too much generally, and you get away with it.
Comment 7 Horst H. von Brand 2011-03-15 21:48:30 EDT
You are right, I didn't think of that. Any "save state away for clean restarting" will be used once in a blue moon, i.e., will bit rot and not be worth the development effort. 

Perhaps just the price to pay for increasing complexity.

Thanks for your time.
Comment 8 Horst H. von Brand 2011-04-15 10:51:54 EDT
(In reply to comment #2)
> a) Had no LibreOffice running
> b) opened a .xls, it started up with fairly reasonable speed.
> c) closed the .xls, LibreOffice shutdown
> 
> Is the quickstarter enabled or disabled, I feel like I've asked this question
> before. See tools->options->memory->enable systray quickstarted, if the
> quickstarter is enabled then just disable it

OK, happened to me agian today.


Had the quickstarter running, tried "oocalc somefile.ods", oocalc just exited without any further indication. Tried again, same result. Tried the "Open existing document" on the file, nothing.

Killed all soffice, started "oocalc somefile.ods" normally, on exit the process still hang on to the Terminal, noticed the LOo icon was again there. Killed that one, and ran ooffice, icon showed up again, could exit that one and now it works.

I updated glib2 in the meantime...

glib2-2.28.6-2.fc15.x86_64
glib2-2.28.6-2.fc15.i686
libreoffice-core-3.3.2.2-6.fc15.x86_64
Comment 9 Caolan McNamara 2011-10-21 10:19:57 EDT
Dunno, this whole bug baffled me. *hopefully* we addressed it, we did at least drop the quickstarter by default and made a pile of improvements anyway to try and do the right thing if its running and an update happened. I think that's as much as I can do with it

Note You need to log in before you can comment on or make changes to this bug.