Skip to content

based refactors: Simplify IPC channels and cleanup#4144

Open
nrwahl2 wants to merge 23 commits into
ClusterLabs:mainfrom
nrwahl2:nrwahl2-based_first
Open

based refactors: Simplify IPC channels and cleanup#4144
nrwahl2 wants to merge 23 commits into
ClusterLabs:mainfrom
nrwahl2:nrwahl2-based_first

Conversation

@nrwahl2

@nrwahl2 nrwahl2 commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

This is the next batch from #4011.

The responsible commits were written before we replaced all gpointers
with void pointers.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
@nrwahl2
nrwahl2 requested a review from clumens July 6, 2026 19:41
Comment thread etc/sysconfig/pacemaker.in
Comment thread lib/common/mainloop.c Outdated
Comment thread lib/common/ipc_server.c
pcmk__assert(cb != NULL);

return mainloop_add_ipc_server(CRM_SYSTEM_CRMD, QB_IPC_SHM, cb);
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessarily for this PR, but I don't see why pcmk__serve_controld_ipc should have a different prototype from all the other similarly named functions.

@nrwahl2 nrwahl2 Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started adding a commit for this. I see only one reason why the controller's "serve IPC" function should be treated differently from the others.

  • If it fails in ipc_proxy_init(), we exit fatally.
  • If it fails in the controller's startup (do_started()), we shut down the controller and inhibit respawn by registering an error input.

The other pcmk__serve_*_ipc() functions exit fatally no matter what.

We can still make it more similar to the other functions, including using the same prototype.

Comment thread daemons/based/based_callbacks.c
@clumens clumens added the review: in progress PRs that are currently being reviewed label Jul 14, 2026
nrwahl2 added 19 commits July 14, 2026 15:20
There were four allowed values: shared-mem, socket, posix, and sysv.

Libqb removed support for posix and sysv (message queues) in 2012 via
commit 70a9623a. It simply returns an error if you try to set up those
types of IPC.

I spoke with the libqb maintainers last night, and they said that socket
IPC has never worked correctly and that they are considering removing
it. Sockets were mainly intended for systems where shared memory was not
available. That is believed to be no longer applicable -- shared memory
should be available on all the platforms that Pacemaker and libqb
target for support.

That leaves only shared memory as a working option.

We are dropping this option rather than deprecating it. As discussed
above, two of the values (posix and sysv) will fail immediately during
IPC setup, and socket is very buggy. So user-facing behavior should not
be affected. If the option is configured, it will simply be ignored.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
QB_IPC_NATIVE tells libqb to use shared memory (QB_IPC_SHM) unless it's
shared-memory IPC is specifically disabled at build time because it's
unavailable on the system. In that case, libqb will use sockets
(QB_IPC_SOCKET).

I spoke with the libqb maintainers last night, and they said that socket
IPC has never worked correctly and that they are considering removing
it. They told me never to use libqb socket IPC.

Libqb socket IPC was mainly intended for systems where shared memory was
not available. That is believed to be no longer applicable -- shared
memory should be available on all the platforms that Pacemaker and libqb
target for support.

The maintainers weakly suggested using QB_IPC_NATIVE (rather than
QB_IPC_SHM). I suppose this was for future-proofing ("let libqb decide
what to use"). Nonetheless, since we have a couple of use cases where we
MUST avoid blocking, and QB_IPC_SHM is non-blocking, we'll just use
QB_IPC_SHM everywhere until we have a reason not to. Besides, this makes
things explicit.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
...argument.

QB_IPC_NATIVE tells libqb to use shared memory (QB_IPC_SHM) unless
shared-memory IPC is specifically disabled at build time because it's
unavailable on the system. In that case, libqb will use sockets
(QB_IPC_SOCKET).

I spoke with the libqb maintainers last night, and they said that socket
IPC has never worked correctly and that they are considering removing
it. They told me never to use libqb socket IPC.

Libqb socket IPC was mainly intended for systems where shared memory was
not available. That is believed to be no longer applicable -- shared
memory should be available on all the platforms that Pacemaker and libqb
target for support.

The maintainers weakly suggested using QB_IPC_NATIVE (rather than
QB_IPC_SHM). I suppose this was for future-proofing ("let libqb decide
what to use"). Nonetheless, since we have a couple of use cases where we
MUST avoid blocking, and QB_IPC_SHM is non-blocking, we'll just use
QB_IPC_SHM everywhere until we have a reason not to.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
It behaves identically to cib_command. This became even more clear with
the recent "Use QB_IPC_SHM in pcmk__serve_DAEMON_ipc()" commit.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
And associated code. It behaves identically to PCMK__SERVER_BASED_RW.

A key point to note is that only non-proxied cib_native clients
connected to PCMK__SERVER_BASED_SHM (prior to deprecation of
cib_command_nonblocking in a previous commit). cib_remote clients and
proxied connections used only PCMK__SERVER_BASED_RO and
PCMK__SERVER_BASED_RW. So backward compatibility should not be a concern
-- this affects only local clients on a cluster node.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
It has one caller and saves one line at most.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
And make the mainloop variable static. No other code changes.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
There is still more work to do to consolidate/reorganize the based
exit/shutdown-related code. I'm keeping the pieces small to try to make
it easier to reason about. based_terminate() seems too complicated.

Note that based_ipc_cleanup() calls pcmk__client_cleanup(), which is why
we drop the call from main.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
There are two call sites.
* based_cpg_destroy: This is called only via the main loop. See
  pcmk_cluster_set_destroy_fn() and pcmk__cpg_connect().

* based_shutdown: We can reach this only through the main loop. It's set
  up as a main loop signal handler via mainloop_add_signal(). The true
  signal handler is mainloop_signal_handler(), which sets a main loop
  trigger to call based_shutdown(). That trigger can't do anything
  unless the main loop is running.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Mostly for sanity. Between the g_main_loop_quit() call and the main loop
actually stopping, the main loop runs callbacks for any sources that
have already been dispatched. In case some callback actually runs, it
should be able to call based_shutting_down() and get a true return
value.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
We were allocating an int to hold the server socket file descriptor, and
we were never freeing it. (Its destroy callback,
based_remote_listener_destroy(), did not free it.)

Don't allocate an int, but instead call GINT_TO_POINTER() and
GPOINTER_TO_INT() to cast it to and from a pointer.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
We will use this soon.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Previously we were only closing the file descriptors. Instead we destroy
the mainloop_io_t objects returned by mainloop_add_fd(). In order to do
that, we need to start storing those objects in the first place.
Previously we were ignoring the return value of mainloop_add_fd() in
init_remote_listener().

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Return false early where possible instead.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Also take a const argument. This function may kill a process, but it
doesn't modify the mainloop_child_t.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
@nrwahl2 nrwahl2 removed the review: in progress PRs that are currently being reviewed label Jul 14, 2026
@nrwahl2
nrwahl2 force-pushed the nrwahl2-based_first branch from 552e2ce to fce9934 Compare July 14, 2026 22:46
@nrwahl2

nrwahl2 commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

Updated to address review. However, I'm finding at least one issue in cts-lab:

Jul 14 16:08:40	Running test RemoteStonithd         (fastvm-fedora42-25) [  6]
Jul 14 16:11:51	Warning: core file on fastvm-fedora42-22: Tue 2026-07-14 16:09:33 PDT 35680 189 189 SIGABRT present /usr/libexec/pacemaker/pacemaker-controld 546.7K
Jul 14 16:11:51	Warning: core file on fastvm-fedora42-24: Tue 2026-07-14 16:10:51 PDT 27014 0 0 SIGABRT present /usr/libexec/pacemaker/pacemaker-fenced 473.2K
Jul 14 16:11:52	Audit FileAudit FAILED.
Jul 14 16:12:07	BadNews: 1784070573.280380 fastvm-fedora42-22 pacemaker-controld[22665]:  error: handle_glib_message: Forked child [35680] to record non-fatal assertion at logging.c:161 : g_hash_table_foreach_remove_or_steal: assertion 'version == hash_table->version' failed
Jul 14 16:12:07	BadNews: 1784070573.280458 fastvm-fedora42-22 pacemaker-controld[22665]:  notice: Blackbox dump requested, please see /var/lib/pacemaker/blackbox/pacemaker-controld-22665.1 for contents
Jul 14 16:12:07	BadNews: 1784070573.280552 fastvm-fedora42-22 pacemaker-controld[22665]:  error: Failed to write blackbox file /var/lib/pacemaker/blackbox/pacemaker-controld-22665.1: No such file or directory
Jul 14 16:12:07	BadNews: 1784070573.375827 fastvm-fedora42-22 pacemaker-controld[22665]:  crit: GLib: g_hash_table_foreach_remove_or_steal: assertion 'version == hash_table->version' failed
Jul 14 16:12:21	BadNews: 1784070651.789342 fastvm-fedora42-24 pacemaker-fenced[22005]:  error: handle_glib_message: Forked child [27014] to record non-fatal assertion at logging.c:161 : g_hash_table_foreach_remove_or_steal: assertion 'version == hash_table->version' failed
Jul 14 16:12:21	BadNews: 1784070651.789426 fastvm-fedora42-24 pacemaker-fenced[22005]:  notice: Blackbox dump requested, please see /var/lib/pacemaker/blackbox/pacemaker-fenced-22005.1 for contents
Jul 14 16:12:21	BadNews: 1784070651.789609 fastvm-fedora42-24 pacemaker-fenced[22005]:  error: Failed to write blackbox file /var/lib/pacemaker/blackbox/pacemaker-fenced-22005.1: No such file or directory
Jul 14 16:12:21	BadNews: 1784070651.912261 fastvm-fedora42-24 pacemaker-fenced[22005]:  crit: GLib: g_hash_table_foreach_remove_or_steal: assertion 'version == hash_table->version' failed

The only thing that added a call to g_hash_table_foreach_remove() is the "Track mainloop children in a hash table" commit, so that's the prime suspect. I'll rebuild without that commit and run cts-lab again.

@nrwahl2
nrwahl2 marked this pull request as draft July 14, 2026 23:18
@nrwahl2 nrwahl2 added the waiting for author Review has been provided, and we're waiting for a response from the author of the pull request label Jul 14, 2026
nrwahl2 added 2 commits July 14, 2026 18:16
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Make it as similar as possible to the other pcmk__serve_X_ipc()
functions.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Since it's the legacy equivalent of "controld".

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
@nrwahl2

nrwahl2 commented Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

The only thing that added a call to g_hash_table_foreach_remove() is the "Track mainloop children in a hash table" commit, so that's the prime suspect. I'll rebuild without that commit and run cts-lab again.

Yeah, it appears to work fine without that commit. Nothing depends on that commit, so I'll drop it for now.

@nrwahl2
nrwahl2 marked this pull request as ready for review July 15, 2026 01:17
@nrwahl2
nrwahl2 force-pushed the nrwahl2-based_first branch from fce9934 to 0fd5c78 Compare July 15, 2026 01:17
@nrwahl2 nrwahl2 added needs attention PRs that someone needs to look at and removed waiting for author Review has been provided, and we're waiting for a response from the author of the pull request labels Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs attention PRs that someone needs to look at

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants