Based on the following user report:
I ran into an issue where I was seeing a long delay in the scripts called
in udhcp_run_script. I was using an old version of OpenWrt (kamikaze)
and a satellite modem. An NTP script was being called and the modem
would sometimes take a long time to respond to the DNS lookup when
it was offline.
This delay started affecting my lease time. The lease that I would
get from my satellite modem before it was online would be short:
only 60 seconds. The delay with NTP and the modem would typically
be about 18 seconds. This would cause the first DHCP renew request
from dhcpc to be a little late. Under certain circumstances,
I could even see the first DHCP renew to occur after the lease
had expired!
function old new delta
udhcpc_main 2816 2837 +21
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The --bb options now depends on LONG_OPTS. Omit mentions of --bb from usage
text when LONG_OPTS is disabled.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The problem seemed to be that it crashes if the t_intrc special character is set to -1 on a pty. I worked around this by setting it to an obscure control character instead in that case.
The Required_argument macro is only defined when long options are enabled.
Fixes the following build error:
miscutils/nandwrite.c: In function 'nandwrite_main':
miscutils/nandwrite.c:120:10: error: expected ',' or ';' before 'Required_argument'
Reported-by: Christian Kästner <kaestner at cs.cmu.edu>
Signed-off-by: Baruch Siach <baruch at tkos.co.il>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
In vi-mode lineedit tries to detect some escape sequences.
After the ESC it reads the next character to check for certain
values. This read should have a timeout or a user-entered ESC to
switch to command mode doesn't properly handle the next character.
Signed-off-by: Ron Yorston <rmy@tigress.co.uk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The support for OA-left/right on GNO uses the OA2META ioctl option to map OA-x to ESC x.
VT100-type terminal emulators have significant variations in what modifier combinations they'll pass through and what escape sequences they produce. Hopefully at least one of them works on just about everything.
This was broken by the change to using CRMOD mode, which actually does mapping on input as well as output. The fix is to set the terminal to "vt100 arrow" mode, which is an undocumented option that translates arrows to vt100-style escape sequences (also used by gsh).
(Note that the earlier patch actually makes us use CRMOD mode most of the time, not non-CRMOD mode as the summary erroneously says.)
This is important because CRMOD mode prevents text from backgrounded programs from being printed properly. It also leaves the terminal in an inappropriate state if hush crashes or is killed.
For the time being, we still switch briefly to CRMOD mode when we want to print just a CR.
Man entry for sendfile:
Not specified in POSIX.1-2001, or other standards.
Other UNIX systems implement sendfile() with different semantics and
prototypes. It should not be used in portable programs.
Select PLATFORM_LINUX if enabling FEATURE_USE_SENDFILE.
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
some flash partitions can be smaller than the existing BUFSIZE thus write
BUFSIZE will fail with "no space left on device"
Signed-off-by: Jacob Kjaergaard <jacob.kjaergaard@prevas.dk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This is done by adding new memory allocation routines that use the current process's userID, so the memory will be deallocated when it quits or execs, even if it's a forked child process.
The bug is that an #if condition may be mis-evaluated if it immediately follows a use of a function-like macro. I also modified a couple other places that could possibly trigger the bug (including a possibly more reliable fix for the instance of this problem I worked around earlier in include/xatonum.h).
We do this by maintaining a mask (for each pid) giving the fds to be closed on exec. We wrap functions that close fds so that their close-on-exec bits can be cleared at that point.
This implementation may close the fds even if the execve operation ultimately fails.
Also, fix issue where callers of getopt32() weren't properly detecting errors on GNO due to a size mismatch.
This avoids strange behavior when commands using getopt32 (like export) are invoked multiple times, sometimes with invalid arguments.
This avoids problems stemming from the fact that GNO's environment implementation may deallocate those strings, in some cases before we're done with them. It also allows us to uppercase the variable names, although since we made them case-insensitive this only matters for display purposes (in "set" output).
This avoids a problem where one of the SIGALRM signals could be delivered after the original SIGALRM handler was restored, which would normally cause the process to terminate.
For now, we just rely on polling in a loop to determine when the child is done. This isn't optimal, but should be OK. If procsend() worked, we could use that in the child to signal the parent. However, procsend() is broken in GNO 2.0.6 -- it seems that it actually tries to invoke the send() call for sockets, but with the wrong arguments, leading to a crash.
Busybox already uses sendfile in httpd. This patch proposes to use it
globally to copy data between file descriptors.
It speeds up the copying on slow systems a lot - below are the times needed
to copy a 450Mb file with and without this option enabled on a BeagleBone
Black:
sendfile:
user 0m0.000s
sys 0m8.170s
read/write 4k:
user 0m0.470s
sys 0m16.300s
function old new delta
bb_full_fd_action 394 474 +80
Signed-off-by: Bartosz Golaszewski <bartekgola@gmail.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Sometimes ARG_MAX is small (like 32k) yet sysconf(_SC_ARG_MAX)
is big, and people prefer using the bigger value.
OTOH, with sufficiently large ARG_MAX, further wins from
sysconf(_SC_ARG_MAX) being bigger are exponentially smaller:
you can see 4 times fewer fork+execs when you run find, but
when each execed process already takes a thousand parameters
it's likely execution time is dominated by what that process
does with each parameter.
Thus, with this change ARG_MAX is used if it's sufficiently big,
otherwise sysconf(_SC_ARG_MAX) is used.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Denys Vlasenko
Baruch Siach
Stephen Heumann
Baruch Siach
Ron Yorston
Bartosz Golaszewski
Jacob Kjaergaard
Bartosz Golaszewski