LXD refuses to start if kernel does not support AIO #228
Comments
|
The AIO requirement is documented in README.md in this repo -- I can add a note in the dqlite, go-dqlite, and lxd repos as well. The specific error here is a null pointer dereference because |
|
Error message should now be something like: Not the greatest, but better than a panic. Maybe it would be a good idea to modify |
What do you think of changing the behavior of The only exception to the above behavior would perhaps be if |
|
That seems reasonable to me. I assume the current behavior (clearing the |
I don't think there's a particular reason for the current behavior. As long as we document that The idiomatic way would be something like: int rc;
dqlite* node;
rc = dqlite_node_create(..., &node);
if (rc != 0) {
if (rc == DQLITE_NOMEM) {
printf("out of memory\n");
} else {
printf("%s\n", dqlite_node_errmsg(node));
dqlite_node_destroy(node)
}
exit(-1); /* or whatever */
} |
|
Now that the AIO requirement is documented everywhere and the go-dqlite error message is fixed (see canonical/go-dqlite#199) I think this can be closed? |
|
That seems reasonable to me. I assume the current behavior (clearing the
`struct dqlite_node`) is defense in depth against callers who neglect to
check for errors -- maybe we could address that concern in some other way.
…On Wed, Aug 24, 2022 at 3:04 PM Free Ekanayaka ***@***.***> wrote:
Error message should now be something like:
Error: create node: failed to create node: internal dqlite error
Not the greatest, but better than a panic. Maybe it would be a good idea
to modify dqlite_node_create to allow returning an error string (using
some other channel than the errmsg field of struct dqlite_node)? Then we
wouldn't have to interpret the rather non-specific return code in go-dqlite.
What do you think of changing the behavior of dqlite_node_create() so
that even if it returns an error, it does *not* free the dqlite_node **n
pointer, so call sites can invoke dqlite_node_errmsg() to extract the
error message, and then call dqlite_node_destroy() to free the memory.
The only exception to the above behavior would perhaps be if
dqlite_node_create fails with DQLITE_NOMEM, but it's a minor detail
practically speaking, probably something we don't need to worry too much in
real world.
—
Reply to this email directly, view it on GitHub
<#228 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMYX2CWHN2JM3YBN2VMBIQDV2ZW3VANCNFSM5DZS2TNA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Originally reported at https://github.com/lxc/lxd/issues/9189
I had to compile my own kernel for various reasons, and while I was doing so I figured to harden it a little. Among other things, I decided to disable AIO because it's typically defined as legacy and has had many security issues in the past (besides, io_uring is the new kid on the block).
However, once running on this kernel, 'lxd init --preseed' no longer works because lxd won't start. In the logs the following stack trace is found:
If it is intended for AIO to be required, my suggestion would be to document this (the only reference to AIO I could find is a recommendation for aio-max-nr sysctl) and maybe add some error handling so LXD doesn't just panic.
Required information
The text was updated successfully, but these errors were encountered: