The callback function registered to be invoked when subscribing to a
notification was only passed the notification data (if any) but not the name
of the notification.
This name is now passed as second argument to remain backwards compatible.
The example subscriber.lua has also be updated.
Signed-off-by: Dirk Feytons <dirk.feytons@gmail.com>
==18834== Warning: invalid file descriptor -1 in syscall close()
==18834== at 0x5326D20: __close_nocancel (syscall-template.S:84)
==18834== by 0x5046DC7: ubus_process_obj_msg (libubus-obj.c:143)
==18834== by 0x5045E98: ubus_process_msg (libubus.c:106)
==18834== by 0x50468D0: ubus_handle_data (libubus-io.c:314)
==18834== by 0x4E3D125: uloop_run_events (uloop.c:198)
==18834== by 0x4E3D125: uloop_run_timeout (uloop.c:555)
==18834== by 0x109BEF: uloop_run (uloop.h:111)
==18834== by 0x109BEF: main (main.c:25)
Signed-off-by: John Crispin <john@phrozen.org>
valgrind complained about this one
==18632== Warning: invalid file descriptor -1 in syscall close()
==18632== at 0x5326D20: __close_nocancel (syscall-template.S:84)
==18632== by 0x5046C02: ubus_process_invoke (libubus-obj.c:98)
==18632== by 0x5046DC3: ubus_process_obj_msg (libubus-obj.c:142)
==18632== by 0x5045E98: ubus_process_msg (libubus.c:106)
==18632== by 0x50468D0: ubus_handle_data (libubus-io.c:314)
==18632== by 0x4E3D125: uloop_run_events (uloop.c:198)
==18632== by 0x4E3D125: uloop_run_timeout (uloop.c:555)
==18632== by 0x109BEF: uloop_run (uloop.h:111)
==18632== by 0x109BEF: main (main.c:25)
Signed-off-by: John Crispin <john@phrozen.org>
Even with the tx_queue-ing issue resolved, what
seems to happen afterwards, is that all the messages
seems to get through, but the client still loops
in the `ubus_complete_request()` waiting for
`req->status_msg` or for a timeout.
Though, the timeout does not seem to happen, because
the data is processed in `ubus_poll_data()`, with
a infinite poll() timeout (ubus_complete_request() is
called with timeout 0).
It's likely that either the `seq` or `peer` sent from
ubusd are wrong, and the client cannot get the correct
ubus request in `ubus_process_req_msg()`.
I haven't digged too deep into this ; setting the
`retmsg` object on the client struct seems to have
resolved any hanging with the `ubus list` command.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [fix placement of retmsg in cl]
Should save a few cycles, since the data that's
being changed is only the seq number.
And the `ub` is always created as shared.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This makes it clear that `ubus_msg_send()` is only
about sending and queue-ing messages, and has nothing
to do with free-ing.
It can be a bit misleading/confusing when trying to go
through the code and make assumptions about whether a
buffer is free'd in ubus_send_msg(), or is free'd outside.
In `ubusd_proto_receive_message()` the `ubus_msg_free()`
is now called before the `if (ret == -1)` check.
That way, all callbacks will have their messages free'd,
which is what's desired, but confusing, because:
* ubusd_handle_invoke() called ubus_msg_free() before returning -1
* ubusd_handle_notify() called ubus_msg_free() before returning -1
* ubusd_handle_response() called ubus_msg_send(,,free=true) before returning -1
* ubus_msg_send() would call ubus_msg_send(,,free=false)
* all other callback callers would `ubus_msg_send(,,free=true)`
(free the buffers in ubus_msg_send() )
In all other places, where `ubus_msg_send(,,free=true)`
an explicit `ubus_msg_free()` was added.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Objects are stored in the ubus context in an AVL tree. An AVL tree
node contains a pointer to a key value. For the ubus context, this
points to the id member of the object structure. In
ubus_remove_object_cb, the id member is set to zero and then after,
avl_delete is called and fails. To fix this, we call avl_delete
before setting the object id to zero.
Signed-off-by: Bob Ham <bob.ham@tomltd.co.uk>
Variable listen_timeout is redefined as a function resulting into
a compile issue. Define the function as ubus_cli_listen_timeout
to fix the compile issue.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
When ubus connect fails ctx->sock.eof will be set but ctx->sock.error
can be set as well. Reset ctx->sock.error as well when doing ubus
reconnect
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
For a shared ubus_msg_buf, the ubus_msg_ref function will
create a copy for queue-ing.
Problem is, that during the dequeue (especially) in client_cb,
the header is 0-ed (because it's was a newly alloc-ed buffer).
And during ubus_msg_writev(), the header info will be ignored
by the client.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
uloop_cancelled was used for two purposes within ubus_complete_request:
- interrupting recursive requests on SIGINT/SIGTERM
- breaking out of the poll loop in a recursive request that completed
Saving/restorung uloop_cancelled was buggy, leading to SIGTERM not being
processed properly. Simplify the logic by using a separate field for
internal use
Signed-off-by: Felix Fietkau <nbd@nbd.name>
An -1 returned by ubus_msg_writev() will be interpreted as
UINT_MAX during a check to see how much data had could be
written on the socket.
Because sizeof() will return size_t it will promote the
comparsion to unsigned
Signed-off-by: Mihai Richard <mihairichard@live.com>
If a synchronous operation is executed on a ubus context after
uloop_done() has been called, the context's pending_timer
may remain in uloop's list of timeouts.
This leads to undefined behaviour during next execution of uloop
code, as it may be referring to unavailable memory or memory
that has been allocated for different purposes.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Abhimanyu Vishwakarma <Abhimanyu.Vishwakarma@imgtec.com>
Add Lua bindings for 'ubus_defer_request' and 'ubus_complete_deferred_request' functions with sample code.
Signed-off-by: Vasily Goldobin <vasily@lynxtech.ru>
We seem to be getting timeout for ubus wait_for calls
every now and then.
And it's not reliably reproducible.
Looking at the code the only thing that would look like
a potetntial reason, is that between the ubus_lookup() and
ubus_register_event_handler() calls, there's a very narrow
window where the event would get sent out and we would not
get it, thus having to timeout.
It doesn't look like registering the event handler first
is a big problem for the whole wait_check_object() logic.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
If there are any ACLs present other than global wildcard "*", the AVL
tree comparator will compare ACL key to object name. However, object
name can be NULL in cases where ACL check is done on call to internal
ubus objects (e.g. ubus monitor).
With this change we skip checking ACLs on such NULL objects.
Signed-off-by: Denis Osvald <denis.osvald@sartura.hr>
Patch by Delio Brignoli <brignoli.delio@gmail.com>
Both ubusd_free_object (eventually via ubusd_create_object_event_msg)
and ubus_proto_send_msg_from_blob() use the same message buffer.
So ubusd_handle_remove_object builds the payload which gets (indirectly)
overwritten by the call to ubusd_free_object and then sent again by
ubus_proto_send_msg_from_blob.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Both ubusd and cli TARGET_LINK_LIBRARIES reference ${json} which is
obtained via find_library(), but since the find_library() is searched
after the TARGET_LINK_LIBRARIES for ubusd, ubusd always gets an empty
${json} variable.
examples/server also links against libjson-c, but we were not setting
TARGET_LINK_LIBRARIES accordingly, so do that too with ${json} appended.
This was causing linking errors for ubusd and then examples/server using
an external toolchain (stbgcc-4.8-1.x).
Fixes: 9f52d1769b ("cli: use the new json-c library name")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
62cdfc3 added systemd units including a ubus.socket unit, but didn't
actually add socket activation support to ubusd. This would cause the first
connection that activated ubusd to hang (as ubusd ignored it), and stopping
ubusd would break it completely (as ubusd removed the socket file).
The ENABLE_SYSTEMD default is changed to OFF as the socket activation uses
libsystemd, so setting ENABLE_SYSTEMD to ON will now require libsystemd.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
If the ubus_reconnect() call fails in ubus_connect_ctx(), the msgbuf.data
newly allocated buffer is freed, but its pointer in the ubus_context is not
removed.
This leads to a double free error if ubus_auto_shutdown() is called for cleanup
after ubus_auto_connect() failed to connect to ubusd.
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
Currently 'ubus listen' command does not respect the timeout parameter,
i.e., whether timeout parameter is provided, 'ubus listen' will always
run infinitely. This patch let 'ubus listen' command support the timeout
parameter. For example, 'ubus listen -t 60' will cause the command to
exit after 60 seconds.
Signed-off-by: Zhao, Gang <gang.zhao.42@gmail.com>
Function ubus_cli_listen() is called only once, and function uloop_run()
and uloop_done() which need struct ubus_event_handler listener are
called within this function, so it's not needed to mark struct
ubus_event_handler listener as static. The same as pointer struct
ubus_context *ctx in main function.
Global struct commands is only used in this file, so it should be marked
static.
Signed-off-by: Zhao, Gang <gang.zhao.42@gmail.com>
Changing the ubus message header fields from 'host' order to 'network' order
allows passing ubus messages between hosts with different endianity.
Example use (creating a ubus proxy):
on host A (e.g. big endian router already running ubusd), run:
$ socat TCP-LISTEN:5699,fork UNIX:/var/run/ubus.sock &
On host B (e.g. little endian development PC) run:
$ socat UNIX-LISTEN:/var/run/ubus.sock,fork TCP:<host A IP>:5699 &
Now ubus applications can be run on host B and seamlessly interact with ubus
applications on host A.
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
Add ubus_auto_shutdown function, which ensures any pending uloop_timer is cancelled before calling ubus_shutdown on the context.
This avoids a condition where ubus_shutdown() is called during ubus_auto_connect attempting a reconnection.
Signed-off-by: Ben Kelly <ben@benjii.net>
At the moment, we do our own null checks before calling ubus_free().
The likely-hood of 'ctx' being null (in ubus_free()) is low,
but since free() handles null, might make sense for ubus_free() to do so as well.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
