Bug 784675 - corosync master: regression(s) in service shutdown
Summary: corosync master: regression(s) in service shutdown
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Corosync Cluster Engine
Classification: Retired
Component: unknown
Version: 1.4
Hardware: All
OS: All
urgent
urgent
Target Milestone: ---
Assignee: Fabio Massimo Di Nitto
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-25 19:18 UTC by Fabio Massimo Di Nitto
Modified: 2012-01-31 09:21 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-31 09:21:34 UTC


Attachments (Terms of Use)

Description Fabio Massimo Di Nitto 2012-01-25 19:18:52 UTC
Description of problem:

exec_exit_fn is never executed when corosync is shutdown.

Version-Release number of selected component (if applicable):

git master
HEAD: f25d5829f25442e6364228ae65e6f74c020ee00b

How reproducible:

Always

Steps to Reproduce:
1. Either define a exec_exit_fn to do something or notice the missing logs entries on shutdown for:
Jan 25 20:09:27 notice  [SERV  ] Service engine unloaded: corosync vote quorum service v1.0

2. start corosync in foreground/debug mode
3. hit ctrl+c
  
Actual results:

^C
Jan 25 20:09:27 notice  [SERV  ] Unloading all Corosync service engines.
Jan 25 20:09:27 notice  [MAIN  ] Corosync Cluster Engine exiting normally


Expected results:

Jan 25 20:09:27 notice  [SERV  ] Unloading all Corosync service engines.
Jan 25 20:09:27 notice  [SERV  ] Service engine unloaded: corosync extended virtual synchrony service
[several services unload messages]
Jan 25 20:09:27 notice  [MAIN  ] Corosync Cluster Engine exiting normally

Additional info:

the problem is in corosync_service_unlink_priority

-                       snprintf(key_name, ICMAP_KEYNAME_MAXLEN,
-                                       "internal_configuration.service.%u.handle",
-                                       corosync_service[*current_service_engine]->id);
-                       if (icmap_get_uint64(key_name, &found_service_handle) == CS_OK) {

the .handle icmap key does not exists anymore, and there for the check is not required.

by commenting out the check (since we parse a list of only known objects that could also be improved to avoid unnecessary looping), we execute again exec_exit_fn.

also to notice that the service shutdown order is not correct.

If we load service 1, 2, 3, 4, the expected shutdown order should be 4, 3, 2, 1. I can see from the logs that the unload order is the same as load.

This can possibly lead to errors in shutting down 4 that depends on 3 or ...


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