Bug 13925 - CLI tools still printing "Unable to initialize messaging context"
CLI tools still printing "Unable to initialize messaging context"
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Other
unspecified
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on: 13465
Blocks:
  Show dependency treegraph
 
Reported: 2019-05-04 11:00 UTC by Ralph Böhme
Modified: 2019-11-13 07:36 UTC (History)
4 users (show)

See Also:


Attachments
WIP patch for master (6.27 KB, patch)
2019-05-04 11:04 UTC, Ralph Böhme
slow: review? (cs)
Details
Patch for 4.10 and 4.11 cherry-picked from master (6.68 KB, patch)
2019-11-07 14:46 UTC, Ralph Böhme
jra: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2019-05-04 11:00:56 UTC
Running command line tools smbclient when run as non root prints the following message

  Unable to initialize messaging context

This is a fallout of the fixes for bug #13465: we call cmdline_messaging_context() in popt_common_credentials_callback() so messaging is initialized before subsequently calling lp_load_client().

With "include = registry" lp_load_client() ends up in dbwrap_open() to open the registry.tdb and there we call messaging_ctdb_connection() which panics internally if messaging is not yet initialzed.

Now instead of having all callers of lp_load*() ensure messaging is initialized, simply ensuring dbwrap_open() initializes messaging itself seems to do the trick.

I have a patch seems to work on a test cluster, tested with testparm and smbclient. Both work and don't print the error message anymore.
Comment 1 Ralph Böhme 2019-05-04 11:04:45 UTC
Created attachment 15119 [details]
WIP patch for master

Christof, can you please take a look and ideally also test it on a cluster?

I came to work on this once again, when I was developing a new CLI tool (mdfind) and I got annoyed by the messaging error message. :)
Comment 2 Christof Schmitt 2019-05-06 21:59:18 UTC
(In reply to Ralph Böhme from comment #0)
> With "include = registry" lp_load_client() ends up in dbwrap_open() to open
> the registry.tdb and there we call messaging_ctdb_connection() which panics
> internally if messaging is not yet initialzed.

I am trying to understand the scenario here. With clustering=yes, we avoid
this case due to the check in cmdline_messaging_context():

	/*
	 * Clustered Samba can only work as root due to required
	 * access to the registry and ctdb, which in turn requires
	 * messaging access as root.
	 */
	if (lp_clustering() && geteuid() != 0) {
		fprintf(stderr, "Cluster mode requires running as root.\n");
		exit(1);
	}

Are you testing with
clustering=no
include=registry?
Comment 3 Ralph Böhme 2019-05-07 05:16:22 UTC
(In reply to Christof Schmitt from comment #2)
No, I'm testing with clustering=yes. :-)

The log message comes from (showing below part of my patch that removes it):

diff --git a/source3/lib/popt_common_cmdline.c b/source3/lib/popt_common_cmdline.c
index 95abec1a440..6d5e13a3160 100644
--- a/source3/lib/popt_common_cmdline.c
+++ b/source3/lib/popt_common_cmdline.c
@@ -102,15 +102,8 @@ static void popt_common_credentials_callback(poptContext con,
        }
 
        if (reason == POPT_CALLBACK_REASON_POST) {
-               struct messaging_context *msg_ctx = NULL;
                bool ok;
 
-               msg_ctx = cmdline_messaging_context(get_dyn_CONFIGFILE());
-               if (msg_ctx == NULL) {
-                       fprintf(stderr, "Unable to initialize "
-                               "messaging context\n");
-               }
-
                ok = lp_load_client(get_dyn_CONFIGFILE());
                if (!ok) {
                        const char *pname = poptGetInvocationName(con);
diff --git a/source3/utils/dbwrap_tool.c b/source3/utils/dbwrap_tool.c
Comment 5 Ralph Böhme 2019-11-07 14:46:59 UTC
Created attachment 15610 [details]
Patch for 4.10 and 4.11 cherry-picked from master
Comment 6 Jeremy Allison 2019-11-08 00:57:24 UTC
Re-assigning to Karolin for inclusion in 4.11.next, 4.10.next.
Comment 7 Karolin Seeger 2019-11-08 09:03:30 UTC
(In reply to Jeremy Allison from comment #6)
Pushed to autobuild-v4-{11,10}-test.
Comment 8 Karolin Seeger 2019-11-13 07:36:13 UTC
(In reply to Karolin Seeger from comment #7)
Pushed to both branches.
Closing out bug report.

Thanks!