I need to verify this, but here's what I think is happening:

1. Mainloop destroys stonith API connection, calling stonith_connection_destroy() on the stonith client.
2. The stonith client sends out T_STONITH_NOTIFY_DISCONNECT notifications via foreach_notify_entry() -> stonith_send_notification().
3. One notification triggers crm_mon.c:mon_st_callback_display() (or event()), which calls mon_cib_connection_destroy().
4. mon_cib_connection_destroy() calls stonith_api_delete(), which calls stonith_api_free() and destroys the entire client object.
5. Control returns to stonith_send_notification() and foreach_notify_entry().
6. One of the further attempts to access members of the stonith client object causes a segfault, since the object and all the members that it owns have been freed.

I've reproduced this on 2.1.0, 2.1.2, and 2.1.7, so it doesn't appear to be a regression. Additionally, it only happens at shutdown, so there's no tangible impact except that it won't reconnect when the cluster starts back... which is not great.

In T620#10902, @nrwahl2 wrote:

However, I'm not sure whether you wanted to include meta-attributes that can be set on a collective for the sole purpose of being inherited by a primitive (sort of the opposite scenario compared to the one above).

• On the one hand: it's cleaner and clearer not to include them, and to include only those meta-attributes that have a direct effect on the collective. We can simply ensure it's documented (maybe it already is) that primitives inherit all of their parents' meta-attributes. That implies that any primitive meta-attribute can be set on a collective for the purpose of inheritance.
• On the other hand: excluding them offloads more work to external tools. For example, if pcs is validating meta-attributes for a bundle, then it needs to check the list of bundle meta-attributes, the list of primitive meta-attributes, and maybe the list of clone meta-attributes. That's not a deal-breaker, but it requires that extra knowledge of Pacemaker behavior be built into external tools.

For the purposes of showing lists, I would think we want to show the meta-attributes that can apply directly to the thing being requested (not just inherited).

In T620#10892, @nrwahl2 wrote:

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

Running a command that generates XML on demand (which is our main goal anyway), and then parsing that, is probably easier than parsing the C code.

If we're using C as the starting point, we don't need XML, we just need tools that can parse the C code (we can require a particular style to make that easier) and generate sysconfig, ReST, and Python.

In T620#10727, @nrwahl2 wrote:

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

This is reasonable as a stylistic choice and as a reminder to update the meta-data when we add an option. However, it doesn't seem either necessary or sufficient in order to guarantee we have one comprehensive list.

In T620#10726, @nrwahl2 wrote:

I feel like internationalization might be easier if we store all the options (with their descriptions, etc.) in C files. Then we can generate XML on demand.

This may also reduce duplication: we can use bit flags for options that are applicable to more than one type of object. It looks like we could do this by referencing an XML entity. However, that strikes me as less intuitive, and it would make the XML files harder to parse. (Parsability by external tools seems like the main advantage of using a static XML file as the source of truth.)

we will likely need some sort of internal API for these that the rest of the code must use to access options (rather than directly access them via getenv() etc.), so that we can guarantee we have one comprehensive list.

It might even be worthwhile to keep the OCF-like metadata in XML files to be used as the definitive list, with the sysconfig file, ReST files for the books, and C and Python data files created from it automatically via make targets. Alternatively, we could install the XML files, and C and Python APIs could parse them.

For pcmk__designated_controller(), it seems reasonable to just ask the local controller for controld_globals.dc_name, using that as the source of truth instead of broadcasting a ping.

• If it's NULL when there is in fact a DC somewhere, that should be a very temporary state, and "no DC" is still "true" from the local perspective.
• If it's set when the DC has gone offline or something, then similar to above.
• If it's possible for multiple nodes to transiently see themselves as DC, then that already complicates the "ping the DC and wait for a response" approach we use now. There's no obviously correct answer in that case.

All of this stems from dropping the mainloops in pcmk_cluster_queries.c. We replaced them with sync when the timeout is 0 in a6ec43e3. We replaced them with poll when the timeout is greater than 0 in 8771565f. The sync change is causing this problem. It's unclear if the poll change has caused or will cause any problems; that seems less likely, but it's possible.

This is now: