search for: guestfs_set_error_handler

The first patch preserves file mode, UID, GID and SELinux context across edited files. The second patch adds a useful new command in guestfish ('llz') which shows SELinux context (like 'ls -laZ') that was useful when debugging this. Rich.

Hi, When I register a callback for events with this function call: eh = guestfs_set_event_callback(g, message_callback, GUESTFS_EVENT_ALL, 0, dev); Shouldnt it capture and redirect messages like this to message_callback(): "libguestfs: error: lstat: /.Trash: No such file or directory" I still get them in stderr .. Thanks, Or

...ple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + * All the 'struct error_data' structures associated with one handle + * are li...

...ple threads. + * + * In each thread, the TLS data is either NULL or contains a pointer + * to a 'struct error_data'. + * + * When it is NULL, it means the stack is empty (in that thread) and + * the default handler (default_error_cb) is installed. + * + * As soon as the current thread calls guestfs_set_error_handler, + * guestfs_push_error_handler, or an error is set in the handle (calls + * like guestfs_int_perrorf and so on), the key is created and + * initialized with a pointer to a real 'struct error_data'. + * + * All the 'struct error_data' structures associated with one handle + * are li...

This is a further, more comprehensive fix for https://bugzilla.redhat.com/show_bug.cgi?id=788641 The guestfish 'edit' command (aka 'emacs', 'vi') suffered from the same problems as virt-edit and more. It could have failed and left a partially overwritten file, and it didn't preserve permissions etc from the original file. These three patches fix all this. The first

...stfs_create_flags with the flag GUESTFS_CREATE_NO_ENVIRONMENT * never prints anything on stderr. If it fails, it sets the * global errno. So something like this should be used: */ fprintf (logfp, "error: %s\n", strerror (errno)); exit (EXIT_FAILURE); } (2) Call guestfs_set_error_handler just after creating the handle: guestfs_set_error_handler (g, NULL, NULL); (3) Call guestfs_parse_environment to parse the environment. This would have been done by guestfs_create, except you set the NO_ENVIRONMENT flag. if (guestfs_parse_environment (g) == -1) { /* see below ... */ (4...

..._CREATE_NO_ENVIRONMENT > * never prints anything on stderr. If it fails, it sets the > * global errno. So something like this should be used: > */ > fprintf (logfp, "error: %s\n", strerror (errno)); > exit (EXIT_FAILURE); > } > > (2) Call guestfs_set_error_handler just after creating the handle: > > guestfs_set_error_handler (g, NULL, NULL); > > (3) Call guestfs_parse_environment to parse the environment. This > would have been done by guestfs_create, except you set the > NO_ENVIRONMENT flag. > > if (guestfs_parse_environment (g)...

Previous discussion here: https://www.redhat.com/archives/libguestfs/2015-June/thread.html#00048 v2: - Use a cleanup handler to release the lock. - Rebase to upstream. Note I have not fixed the problem(s) with error handling (patch 3).

This patch set fixes a two year old bug in guestfish, namely that the 'glob' command does not expand /dev/* patterns. https://bugzilla.redhat.com/show_bug.cgi?id=635971 Rich.

...uestfs_close (guestfs_h *g); extern const char *guestfs_last_error (guestfs_h *g); typedef void (*guestfs_error_handler_cb) (guestfs_h *g, void *data, const char *msg); -typedef void (*guestfs_abort_cb) (void); +typedef void (*guestfs_abort_cb) (void) __attribute__((__noreturn__)); extern void guestfs_set_error_handler (guestfs_h *g, guestfs_error_handler_cb cb, void *data); extern guestfs_error_handler_cb guestfs_get_error_handler (guestfs_h *g, void **data_rtn); -- 1.6.4.2.384.g5fc62

This patch isn't ready to go upstream. In fact, I think we might do a quick 1.30 release soon, and save this patch, and also the extensive changes proposed for the test suite[1], to after 1.30. Currently it is not safe to use the same handle from multiple threads, unless you implement your own mutexes. See: http://libguestfs.org/guestfs.3.html#multiple-handles-and-multiple-threads These

Previously posted in 2015: v1: https://www.redhat.com/archives/libguestfs/2015-June/msg00048.html v2: https://www.redhat.com/archives/libguestfs/2015-June/msg00118.html I have rebased and tidied up the patches, fixing a few spelling mistakes, but they are broadly the same as before. I also ran all the tests, which pass. As with the previous versions, this makes a change to the API, where you

...memory_handler (guestfs_h *g) +{ + return g->abort_cb; } guestfs_abort_cb guestfs_get_out_of_memory_handler (guestfs_h *g) { - return g->abort_cb; + guestfs_abort_cb r; + + ACQUIRE_LOCK (g); + r = unlocked_get_out_of_memory_handler (g); + RELEASE_LOCK (g); + return r; } void guestfs_set_error_handler (guestfs_h *g, guestfs_error_handler_cb cb, void *data) { + ACQUIRE_LOCK (g); g->error_cb = cb; g->error_cb_data = data; + RELEASE_LOCK (g); } -guestfs_error_handler_cb -guestfs_get_error_handler (guestfs_h *g, void **data_rtn) +static guestfs_error_han...

These two patches make appliance building thread-safe. The first adds a test which easily demonstrates the problem. The second fixes the issue. For more information see Ian McLeod's analysis of the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=790528#c5 Rich.

From: "Richard W.M. Jones" <rjones at redhat.com> --- configure.ac | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index fa97479..6e42423 100644 --- a/configure.ac +++ b/configure.ac @@ -141,6 +141,10 @@ if test "$gl_gcc_warnings" = yes; then # Work around warning in src/inspect.c. This seems to be a bug in gcc

...c function. */ + assert (DATA_PTR (m) == NULL); + + flags = parse_flags (argc, argv); + + g = guestfs_create_flags (flags); + if (!g) + rb_raise (e_Error, \"failed to create guestfs handle\"); + + DATA_PTR (m) = g; + + /* Don't print error messages to stderr by default. */ + guestfs_set_error_handler (g, NULL, NULL); + + return m; +} + +/* For backwards compatibility. */ +static VALUE +ruby_guestfs_create (int argc, VALUE *argv, VALUE module) +{ + guestfs_h *g; + unsigned flags; + + if (argc > 1) + rb_raise (rb_eArgError, \"expecting 0 or 1 arguments\"); + + flags = parse_f...

...LE_API_NO >= 20151012 +static void +guestfs_php_handle_dtor (zend_resource *rsrc) +#else static void guestfs_php_handle_dtor (zend_rsrc_list_entry *rsrc TSRMLS_DC) +#endif { guestfs_h *g = (guestfs_h *) rsrc->ptr; if (g != NULL) @@ -191,7 +234,11 @@ PHP_FUNCTION (guestfs_create) guestfs_set_error_handler (g, NULL, NULL); +#if ZEND_MODULE_API_NO >= 20151012 + ZVAL_RES(return_value, zend_register_resource(g, res_guestfs_h)); +#else ZEND_REGISTER_RESOURCE (return_value, g, res_guestfs_h); +#endif } PHP_FUNCTION (guestfs_last_error) @@ -204,15 +251,15 @@ PHP_FUNCTION (guestfs_last_error)...

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

...g) - return luaL_error (L, \"Guestfs.create: cannot create handle: %%s\", - strerror (errno)); + if (!g) { + ignore_value (strerror_r (errno, err, sizeof err)); + return luaL_error (L, \"Guestfs.create: cannot create handle: %%s\", err); + } guestfs_set_error_handler (g, NULL, NULL); @@ -226,6 +230,7 @@ error__tostring (lua_State *L) { int code; const char *msg; + char err[128]; lua_pushliteral (L, \"code\"); lua_gettable (L, 1); @@ -234,8 +239,10 @@ error__tostring (lua_State *L) lua_gettable (L, 1); msg = luaL_checkstring (L,...

...hat.com/show_bug.cgi?id=664558 "RFE: Allow to set log callback in Ruby bindings" How can we make callbacks useful? First off what are we talking about? There are several callbacks that can be registered through the C API: (a) error callback http://libguestfs.org/guestfs.3.html#guestfs_set_error_handler (b) out of memory callback http://libguestfs.org/guestfs.3.html#guestfs_set_out_of_memory_handler (c) log messages from the daemon http://libguestfs.org/guestfs.3.html#guestfs_set_log_message_callback (d) appliance quits http://libguestfs.org/guestfs.3.html#guestfs_set_su...