GNOME Bugzilla – Bug 603468
Improve handling of --quit option
Last modified: 2010-06-12 18:51:59 UTC
Evolution 2.29.3 akhil@lakhil-genesis:~> evolution --force-shutdown Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory (evolution:6567): e-data-server-DEBUG: Loading categories from "/home/akhil/.evolution/categories.xml" (evolution:6567): e-data-server-DEBUG: Loaded 30 categories (evolution:6567): evolution-shell-WARNING **: The name org.freedesktop.NetworkManager was not provided by any .service files evolution-shell-Message: Preparing for online mode... evolution-shell-Message: Online preparations complete. ^[[A^[[A** (evolution:6567): DEBUG: Loading Exchange MAPI Plugin ** (evolution:6567): DEBUG: MAPI listener is constructed with 6 listed MAPI accounts libexchangemapi-Message: exchange-mapi-connection.c:140: exchange_mapi_connection_new: lock(connect_lock) exchange-mapi-connection.c:77: Entering mapi_profile_load Loading profile user@example.com exchange-mapi-connection.c:126: Leaving mapi_profile_load libexchangemapi-Message: exchange-mapi-connection.c:143: exchange_mapi_connection_new: unlock(connect_lock) libexchangemapi-Message: exchange-mapi-connection.c:148: exchange_mapi_connection_new: Connected exchange-mapi-connection.c:2815: Entering exchange_mapi_get_folders_list libexchangemapi-Message: exchange-mapi-connection.c:2817: exchange_mapi_get_folders_list: lock(connect_lock) |---+ Calendar : (Container class: IPF.Appointment C647BD1E00000001) UnRead : 0 Total : 56 size : 464641 |---+ Contacts : (Container class: IPF.Contact C747BD1E00000001) UnRead : 0 Total : 4 size : 7511 |---+ Touch : (Container class: IPF.Contact 990FD9E038000001) UnRead : 0 Total : 2 size : 672 |---+ Deleted Items : (Container class: IPF.Note 0B53BD1E00000001) UnRead : 36 Total : 52 size : 231897 |---+ NCR : (Container class: IPF.Note 396AD9E038000001) UnRead : 4 Total : 17 size : 109986 |---+ Drafts : (Container class: IPF.Note C847BD1E00000001) UnRead : 0 Total : 8 size : 26432 |---+ Dump : (Container class: IPF.Note 5A175EF038000001) UnRead : 5 Total : 6 size : 12266 |---+ Inbox : (Container class: IPF.Note 0853BD1E00000001) UnRead : 27 Total : 85 size : 746669 |---+ Journal : (Container class: IPF.Journal C947BD1E00000001) UnRead : 0 Total : 0 size : 138 |---+ Junk E-Mail : (Container class: IPF.Note EB57BD1E00000001) UnRead : 0 Total : 0 size : 0 |---+ Notes : (Container class: IPF.StickyNote 7BEC5EF038000001) UnRead : 0 Total : 1 size : 200 |---+ Outbox : (Container class: IPF.Note 0953BD1E00000001) UnRead : 0 Total : 81 size : 879527 |---+ Parity : (Container class: IPF.Note E8F7F7EA38000001) UnRead : 10 Total : 29 size : 80737 |---+ PP : (Container class: IPF.Note 58175EF038000001) UnRead : 1 Total : 3 size : 29677 |---+ RSS Feeds : (Container class: IPF.Note.OutlookHomepage 6DEC5EF038000001) UnRead : 0 Total : 0 size : 0 |---+ Sent Items : (Container class: IPF.Note 0A53BD1E00000001) UnRead : 0 Total : 26 size : 677080 |---+ Tasks : (Container class: IPF.Task 63EC5EF038000001) UnRead : 0 Total : 1 size : 578libexchangemapi-Message: exchange-mapi-connection.c:2891: exchange_mapi_get_folders_list: unlock(connect_lock) exchange-mapi-connection.c:2893: Leaving exchange_mapi_get_folders_list evolution-shell-Message: Preparing to quit... No response from Evolution -- killing the process evolution-shell-Message: Quit preparations complete.
This is probably related to my new --force-shutdown implementation. Was Evolution actually running when you invoked that command?
(In reply to comment #1) > This is probably related to my new --force-shutdown implementation. > > Was Evolution actually running when you invoked that command? looks like it happens when evolution crashes and closes abruptly. When i try to do force shutdown after crash, it invokes mapi.
One more scenario : evolution hangs, i close it from terminal by ctrl+c and quit. Now if i try to do force shutdown, it will invoke mapi account.
What's happening is --force-shutdown now invokes "evolution --quit" and waits awhile before killing the process. If no other Evolution process is running, --quit will bring the shell and all the backend modules (including MAPI) online and them immediately initiate shutdown. Running --force-shutdown after Evolution has terminated is pointless right now because it does not terminate the D-Bus services -- only Evolution itself. There's already a bug on file about it (search evolution[dbus] tags). BTW, are you getting "No response from Evolution -- killing the process" every time? The killev program gives Evolution five seconds to shutdown cleanly, but maybe it needs to be longer if some of the backends are taking their time.
Downstream bug report about something similar: https://bugzilla.redhat.com/show_bug.cgi?id=602735 User is asked "want to quit when there are messages in outbox" when he invokes --force-shutdown. (The issue is also with e-util warning about no parent for the question dialog, which is sort of bogus in this case.) I'm moving this bug to evolution, as it's the place where it belongs.
Created attachment 163388 [details] [review] proposed evo patch for evolution; To define a short-hand for a --quit command, to behave like the other evolution is running, even when it isn't. I also used this in the e-mail-backend, to not ask user whether he/she wants to quit when there are unsent messages, because it doesn't make much sense to ask when he/she expressed his/her will by the --quit command. This is the only place where the otherwise construct-only parameter is rewritten. This is not adding closing for factories and alarm notify. We may consider to use other bug report for that, and maybe wait until GDBus will land. (It will, right?)
I think this is a good approach. The only change I'd make is instead of adding a new property, send a "reason for quitting" enumeration value in the "quit-requested" signal so handlers have more knowledge about why a quit is being requested and can act accordingly. Possible values include: - Quit action activated - Last window destroyed - Remote process requested quit (i.e. --quit given) - Session manager requested quit I've also requested this for the new GApplication class that we'll have to switch to soon: https://bugzilla.gnome.org/show_bug.cgi?id=621361
Committed a solution based on Milan's patch: http://git.gnome.org/browse/evolution/commit/?id=51d0fc6863be998af5056605281cc0ebc2abfe00 A few changes: - Define an EShellQuitReason enumeration which is used in the "quit-requested" signal, as described in comment #7. - Split module loading into a new function (e_shell_load_modules()), and skip it calling it if the --quit option is given. This makes --quit noticeably faster, and the shell backends can't interfere because they won't even be loaded.