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>
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>
As the man page explains:
"Specifying a timeout of zero causes poll() to return immediately,
even if no file descriptors are ready."
The use of 0 as timeout could cause libubus to busy loop if the
socket was non-blocking. For blocking sockets, this was less
apparent as the subsequent read() would then block.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
Seems this bug stayed hidden for a while, because the write/sendmsg function
can send up to ~200k in one send, so it looked at first why there was
some data mismatch.
All iov's were sent only after the last were sent (iov_len == 0). We
could have 'cur_len == 0' if the sent iov's were sent wholly but not all
iov's were sent (how about all but the last).
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
