Public bug reported:
Binary package hint: busybox
Hi,
I have a compelling use case that requires that I have automated remote
syslogging capability in the Debian-Installer, as I need to be able to
get installation telemetry and status information from remote installs.
If you at Launchpad bug #160071, you will see that merely restarting
BusyBox's syslog for networking support is insufficient once networking
has been activated. Bug #160071, which ultimately pertains to libdebian-
installer, would be irrelevant if BusyBox's syslogd implementation
actually behaved like the sysklogd software it is modeled after.
The discrepancy in behavior is as follows: Sysklogd uses least effort
delivery mechanisms. If the remote logging host cannot be reached, it
does not block I/O, and it does not attempt to retransmit data. Also, if
the remote logging host cannot be resolved, DNS resolution is deferred
and periodically reattempted. This means that actual sysklogd can be
started with remote logging support before the networking stack has been
activated---e.g., from init.d. On the other hand, BusyBox's
implementation uses best effort delivery mechanisms. BusyBox's cannot be
started with remote logging support before the stack has been enabled,
as it will abort if DNS resolution fails. Secondly, if DNS resolution
works and the remote host cannot be reached, BusyBox's attempts to
resend and sleeps between redelivery attempts with an exponentially-
growing delay.
BusyBox's documentation explicitly states that the software's goal is to
conform as closely as possible to the behavior of the original software.
Per what I have described here, this is definitely a violation of that.
I had a discussion with one of the BusyBox maintainers about this, and
he patched BusyBox's SVN TRUNK version to fix this. With his help, I
took the ethos of his patch and wrote a similar one for the version of
BusyBox that Debian and Ubuntu use.
Attached to this bug is a debdiff patch to the BusyBox source package
that makes its syslogd implementation behavior conform to the actual
behavior of sysklogd, whose behavior it's modeled after.
Give that logging support is needed before networking has been
activated, it cannot be controlled by a preseed file fetched by HTTP.
What I have done then is to modify the rootskel's syslogd starting
script to get the remote logging host and port from the kernel's command
line---/proc/cmdline. I will be filing a separate bug for rootskel
within the next hour.
This is probably most useful to systems administrators and engineers who
are engaging in mass- and remote-deployment applications of Ubuntu
server and workstation.
I have tested this out with the latest Debian-Installer, and everything
appears to work as expected. I plan on submitting this upstream into
Debian within the next few weeks. Since the code freeze for the Hardy
Heron release is fast I approaching, I am submitting this patch to
Ubuntu first in hopes that it can be ushered in very quickly. I will be
working with my friends involved with Debian project to get this
included in the near future to keep the amount of delta between the two
projects low.
Let me know if you have any questions. Let's do what we can to get this
incorporated relatively quickly.
Cheers,
Matt
** Affects: busybox (Ubuntu)
Importance: Undecided
Status: New
--
BusyBox's Syslog Remote Logging Implementation Does Not Behave Like Actual
Sysklogd with Least Effort Delivery Behavior
https://bugs.launchpad.net/bugs/184126
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
