BusyBox's Syslog Remote Logging Implementation Does Not Behave Like Actual Sysklogd with Least Effort Delivery Behavior
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| busybox (Ubuntu) |
Fix Released
|
Medium
|
Colin Watson | ||
Bug Description
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-
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-
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---
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
Related branches
| Matt T. Proud (matttproud-google) wrote | #1 |
| Changed in busybox: | |
| assignee: | nobody → kamion |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Matt T. Proud (matttproud-google) wrote | #2 |
| Colin Watson (cjwatson) wrote | #3 |
| Launchpad Janitor (janitor) wrote | #4 |
| Changed in busybox: | |
| status: | Confirmed → Fix Released |
One thing that I forgot to note: Launchpad bug #178270 may be closed, as this one supersedes it.