Re: udhcpc: throttled down data transmission
I'm using 'udhcpc' on my ARM64 platform with the following scenario: I have one 'eth0' interface that has a static ip address and the 'udhcpc' client on the same interface. That leads to low data transmission performace on that interface. Most people use udhcpc when they *don't* have a static IP address on an interface, the point of DHCP being to assign an IP address. In that common use case, it is impossible to use UDP, since IPv4 is not configured yet! Listening on a raw socket is the only option. Your use case is pretty niche, already having IPv4 configured on your interface before you use udhcpc. It's not surprising that udhcpc isn't optimized for it: it's a small client after all. I suppose it could be patched to add an option to use UDP when the interface already has an address, but it would mean effort, and more code in busybox, which is probably not worth the trade-off. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?
|IIRC writing to /dev/urandom doesn't do what you want it to do. |You have to use an ioctl() to actually set entropy. And that is the sad point about it. Kernel hackers should stand up to allow it again! As Ted Ts'o said[1], and Donenfeld agreed[2], the problem is that any user can write to /dev/urandom, including malicious users, so you cannot credit what they write. I tend to trust people who do the work rather than those who stand on cardboard boxes. Still, since it's related to boot sequence things and I want to be a reliable source on boot sequences, I actually studied the thing when it came up, and understood the issue enough to come up with my own conclusion - and my own conclusion is still that the person who did the work, i.e. Jason, is right about this. I'm sorry. I like the idea of writing stuff to /dev/urandom and have it count, too. It's just not a good idea for security. That's just the way it is. And it would be nice if all the work and ink that already went into it, including mine, could actually be useful to all the people who don't care about any of this and just want their systems to work and be secure - so it would be nice if disinformation and bad ideas stopped being spread. [1]: https://lwn.net/ml/linux-kernel/yjqvemckzcu1p...@mit.edu/ [2]: https://lwn.net/ml/linux-kernel/yjqbcqbyhcopg...@zx2c4.com/ -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFC: initialize /dev/urandom, is it necessary? Can we do it in a better way?
Oh boy. Is it that time of the year again already? In case the /dev/urandom initialisation is a necessity (or a best practice), does it make sense to add it into busybox as an option or as an application? So, there are two different things to address here: 1. the way to add entropy to the kernel's entropy pool in order to make /dev/urandom sufficiently unpredictable; 2. the best way to do this as part of a boot process. For the first thing, the problem is that writing to /dev/urandom adds data to the seed, but does not update the entropy count, because the data you write is not considered creditable (i.e. does not come from a source that is considered random enough to warrant increasing the entropy count). That is the reason for the ioctl: to mark some random data as creditable. That is (a part of) why Jason, who revamped the entire random subsystem in the Linux kernel, wrote seedrng[1]. (Unfortunately, he did not approve the modifications to the version of seedrng that made it into busybox, so use bb seedrng at your own risk. I have an alternative implementation of the same concept, rngseed[2], that follows Jason's design more closely, and has additional options to give more flexibility for e.g. systems with read-only boot disks.) The answer's to Roberto's first question is: yes, initializing /dev/urandom is necessary, but writing stuff to /dev/urandom will not help, even if you consider that stuff random enough. You need a specific tool like seedrng. For the second thing: most of the initialization of a system can happen while the seeding of the entropy pool is in progress. However, at some point, you need a good source of randomness, e.g. when starting an sshd server, and you should have a tool that makes sure the entropy pool is full *before* important services start using it to get their random data. seedrng, or rngseed, fill that role. Writing data to /dev/urandom does not. So the answer to Roberto's second question is: no, the provided script excerpt is *not* suitable for seeding the entropy pool, no matter how much compression, or even how much hashing, you use. On that point, busybox cannot help here. busybox has an implementation of seedrng, but it does not provide a full boot sequence or policy whatsoever; it cannot tell *when* during boot it is appropriate to call seedrng. It is all up to system integrators to write boot sequences that seed the entropy pool correctly and start services securely. [1]: https://git.zx2c4.com/seedrng/about/ [2]: https://skarnet.org/software/s6-linux-utils/rngseed.html -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] nslookup: ensure unique transaction IDs for the DNS queries
You miss the point. CLOCK_MONOTONIC may simply be too granular on some hardware - returning the same value for the duration of several milliseconds. Wait, what? Is that a thing? Is there actual hardware where CLOCK_MONOTONIC stalls for a noticeable period of time? That does not sound permitted by POSIX: > If the Monotonic Clock option is supported, all implementations shall support a clock_id of CLOCK_MONOTONIC defined in . This clock represents the monotonic clock for the system. For this clock, the value returned by clock_gettime() represents the amount of time (in seconds and nanoseconds) since an unspecified point in the past (for example, system start-up time, or the Epoch). This point does not change after system start-up time. Since it's the same language as in the definition of CLOCK_REALTIME, I've always interpreted that as CLOCK_MONOTONIC being mandated to have the same granularity as CLOCK_REALTIME. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox su leaves EUID unchanged
# su userx # id uid=203(userx) gid=203(userx) euid=0(root) Is this expected behaviour? From source I can see it does setuid() which should also modify euid. If not then what could be the issue? As is often the case, the best debug tool here is strace :) What does "strace su userx id" say? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Busybox ash built-in commands fail on unavailable console
Busybox's ash built-in commands -e.g. echo, printf, cd- returns an error
if the stdout/stderr device is not available. In particular, I reached
this behavior while debugging a Debian initramfs, where ash built-in
commands are run during boot, before the console is available.
POSIX mandates that these functions return a nonzero code when an error
occurs. This includes not being able to write to stdout. So the commands
are conforming, it's definitely not a bug.
_log_msg()
{
if [ "${quiet?}" = "y" ]; then return; fi
# shellcheck disable=SC2059
printf "$@"
return 0 # Prevents error carry over in case of unavailable console
}
That is valid.
Another way of proceeding is enforcing set +e at the beginning of
the script, and explicitly exiting on command failures that are deemed
fatal.
* As I'm not sure if this is really a bug or not, I'm sending this as an
RFC. So, the question of this RFC is: should this be considered a bug
and get fixed properly?
Not a bug. What needs to be fixed is the scripts that assume cd, echo
and printf always succeed. Adding "||:" after a command that must always
succeed is easy enough - but hindsight is 20/20 :)
From Busybox ash source code, it can be seen that the *lone-dash* case
`cd -` tries to print to stdout. The other cd cases with the target
directory explicitly set don't fail as they don't try to open the output
device, which is unavailable at that point.
Working as intended: "cd -" is specified to be equivalent to
'cd "$OLDPWD" && pwd', and it's the only case where cd writes to stdout.
I'm afraid cd - >/dev/null is the best workaround you can get.
Shell scripting is fraught with peril, and stdout being unavailable is
a common pitfall.
Good luck,
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support numeric UIDs with a -n flag
You're right. I am a part of a community distro which uses busybox by default, and we need something to be able to change privileges to an arbitrary user, but it is not portable to expect a tool to print all of a username longer than 8 characters. Using the UID is more reliable. There is no standard for su, but my hope with this patch is for there to be one more tool with which our problem can be solved; it's nice to have more options. As much as I understand and sympathize with your plight - I'm the first one to complain about the low quality of "traditional" low-level userspace on Linux - I don't think your approach is the right solution. "su" has - more or less - a known interface, and is - more or less - usable on every distribution; a script using su will generally be portable from one distro to another. Adding an option to busybox su that is not supported by util-linux su destroys that guarantee, and fragments the user space even more than it already is. "su -n" will only be usable with busybox, so to an external viewer, it's more confusing than anything else why the tool is called su. Only use existing tool names when you provide an interface that's exactly compatible with the existing tool; else you will weaken the reach and usefulness of the tool. If you need new functionality, implement the functionality as a separate tool, that can take inspiration from the existing tool for its name and interface, but you should call it ben-su rather than su. Introducing a divergence in busybox su is harmful in the long run. (This is why GNU coreutils is so difficult to replace: it has embraced and extended, and now the world is full of scripts relying on cp --useless-options that every potential replacement has to implement.) For non-interactive applications of su with numeric uids, may I suggest https://skarnet.org/software/s6/s6-applyuidgid.html ? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: suspected bug in timeout command
/* We want to create a grandchild which will watch * and kill the grandparent. Other methods: * making parent watch child disrupts parent<->child link * (example: "tcpsvd 0.0.0.0 1234 timeout service_prog" - * it's better if service_prog is a child of tcpsvd!), * making child watch parent results in programs having * unexpected children.*/ I don't follow this reasoning. Does "disrupts the parent<->child link" just about sending signals? If the timeout app relays all signals from itself to the child, what remaining problems would exist? Yeah, that's clearly a misdesign. Keeping the same pid for the end of a Bernstein chain whenever possible is a good idea, so the intention is good - but it's only possible when the child is *entirely transparent* wrt control flow. It's a good model, for instance, for ssh-agent, or for a data processor such as a TLS tunnel (that's how s6-tlsd operates); but here, since the child actually impacts control (it sends a signal to the parent on timeout) it's just not applicable - and this thread illustrates exactly why. To really fix the bug, timeout should be rewritten, and run as the parent, and possibly forward signals to the child. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Tar component in busybox version 1.34.1 has a memory leak bug when trying to unpack a tar file.
A stock Linux system will happily slaughter your system services with the OOM killer before malloc ever returns NULL. Only if overcommit is activated, which is not a good idea in embedded systems where busybox is likely to be used. Also, resource limits are a thing, and proper administration practices make use of them. malloc returning NULL is not so far out as people think it is, far from it. It *does* happen. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: switch_root and /etc/inittab
I'm not sure I completely understand though. Doesn't "exec" make it run as PID 1? Not if the script containing the "exec" does not run as pid 1 in the first place. When busybox init runs, it runs as pid 1, and stays there until you shutdown the machine. Any script it spawns, even in your ::sysinit lines, will spawn with other pids. So your /bin/init.sh script is not running as pid 1, so switch_root will fail. But I'm not even sure why you want to use switch_root here. switch_root is only useful when you have to boot on an initramfs; from what you've said it doesn't appear necessary for your goal. If you have a rootfs with a functional init, which appears to be the case, you can just boot qemu on that rootfs and it should work. (You might need to turn your rootfs into a disk image first, but the point is that your situation doesn't seem to require an initramfs and switch_root.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Issues with scripts/trylink
Aha. We have CONFIG_EXTRA_LDLIBS. We just need to change the logic so that it is not appended to LDLIBS, but treated separately, with no elision. That would be nice, thanks. Of course, they should be added to the line *before* the LDLIBS, because they may depend on stuff like -lpthread -lrt. Or they could be added, without elision, to the --start-group --end-group blob. (Thanks for the explanation about this.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Issues with scripts/trylink
Greetings, busybox is linked via the scripts/trylink shell script. I have found a couple issues with trylink's management of additional libraries: 1. https://git.busybox.net/busybox/tree/scripts/trylink#n123 This "sanitization" phase changes the semantics of the LDLIBS list. When you give a list of additional libraries, the order is important: higher-level libraries must be given before lower-level ones, else linking might fail. The call to "sort" may change the order, which can break dependencies. The fix is to manually scan the list to remove duplicates without changing the order, which can be achieved with a few lines of shell, but I'm wondering if it's even necessary: giving the same -llib several times on the linking command line does not change the result (there are exceptions, such as when linking libgcc, but those are very special cases, and in those cases all the instances of -l are needed, so if anything it's an argument to keep the lib list as is), and extra spaces do not seem to hurt the rest of the script - except for starting and trailing ones, which are rather easy to remove. I can provide a patch, but I don't want to bother with the whole deduplication thing if the community and the maintainer agree that it can be removed. Or better, see below. 2. https://git.busybox.net/busybox/tree/scripts/trylink#n145 trylink attempts to build with as few additional libraries as it can get away with. This is not correct. In some cases, the libc provides stubs, so linking works without additional libraries, but additional libraries are needed to get the full functionality, so attempting to build without the additional library, seeing that it works, and removing the -l argument yields a binary that does not have the functionality the user wanted. An example is utmp functionality with the musl C library: musl provides utmpx.h stubs that do nothing, and the utmps library ( https://skarnet.org/software/utmps/ ) can be used to implement real utmp functionality on top of musl - but at the moment, busybox cannot be built with utmps, because trylink sees that it links without the "utmps skarnet" arguments (which it reorders as "-lskarnet -lutmps" due to the call to "sort" mentioned above, which would be incorrect even if it kept them), removes them, and makes it impossible to have the desired utmps functionality in the busybox binary. My suggestion is to axe the whole part of the trylink script that attempts to outsmart the user, and to take everything provided as CFLAGS, LDFLAGS and LDLIBS quite literally. (LDLIBS should not even have to add the -l parts before the library names, but we can keep that for compatibility.) If the user wishes to have a convoluted list of LDLIBS, let them; if the busybox binary has too many dependencies as a result, it's on them. As is, trylink is just getting in the user's way, which is antithetic to the minimalism principles that busybox should follow. What do you think? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] coreutils/timeout: send signals to all processes in a group
In current implementation of busybox timeout utility, when a signal is sent to the process that needs to timeout, it does not affect the children. To fix this we set the process group id of the process that the signal is sent, same as it's pid, making it the process group leader. When sending signal, we sent it to negative pid number as per man page and signal is received by all children. That is a very disruptive change that modifies the semantics of 'timeout' entirely, and that leads to unintuitive behaviour for instance wrt ^C when used in a terminal. Well-behaved programs should never need signals sent to the process group, and when a utility does that it should be *very obvious*. At the very least, if the functionality is implemented, it needs to be configurable via a command-line option. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] shrink last_char_is function even more
The param should be marked with the nonnull attribute, just like the libc string functions. Then the compiler will warn you if you try to pass NULL (may need higher optimization, warning levels, or the analyzer mode in complex cases). Indeed. A function that takes a pointer that *cannot* be NULL, and a function that takes a pointer that *may* be NULL, are not the same thing at all. This is one of the main reasons while a lot of people find C pointers difficult: a pointer can be used for two very different things, namely unconditionally representing an object (passing it by address), or representing the *possibility* of an object. In ocaml, the former would would be typed "'a ref", and the latter "'a ref option", and those are *not the same type*. When writing and using a function that takes pointers, a C programmer should always be very aware of the kind of pointer the function expects. It is a programming error to pass NULL to a function expecting a pointer that cannot be NULL, and that error should be caught as early as possible. The nonnull attribute helps detect it at compile time. And at run time, if the function gets NULL, it should crash, as loudly as possible, in order for the bug to be fixed. Checking for NULL "just in case" is defensive programming, which is very bad. It means the programmer does not know exactly what the function contracts are: it would be better named "sloppy programming". Please don't do this. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Sime makelike wrapper scripts support
This is not a general condemnation on implementing a busybox binary that you've just arbitrarily decided "shall not be accepted" simply by fiat, without provided rationale and without being the project maintainer who actually has the right to arbitrarily decide things. But I did provide a rationale: it's creeping featuritis, plain and simple. If you found my posts offensive, be assured that it's nothing compared to how offensive the idea is to me that "mim" and "make" should be part of busybox. No, I'm not the maintainer, thank God. (If I was, I would be forced to be polite and oppose reasonable arguments to unreasonable proposals, and doing this with my own projects without ever losing my temper is enough of a pain in the ass as is.) But I've been a busybox user for long enough, and in enough varied environments, that I happen to have a rather good idea of what would probably be a good fit for busybox and what would not. Sometimes it's not clear-cut, sometimes there are arguments for and against, and it becomes a matter of opinion, and ultimately the maintainer's opinion prevails. "mim" and "make" are not even close. For very different reasons, left as an exercise to the reader for now because I'd like to have dinner soon. So, yeah, that's just my not-humble-at-all opinion, and I'm a peasant, but a peasant who likes his tools and would love to keep them free of useless add-ons. And, unfortunately, who's not always successful at preventing them. And after all, why include patch and diff applets, then reject make on sheer principled outrage? Now *that* is a good question, and a discussion worth having. My answer to it is twofold: - If it had been my decision, patch and diff wouldn't have made it into busybox. That's as simple as that. I've had disagreements with Denys before, and my position is that busybox *already* has too much stuff in it. Other users like it the way it is, because to them busybox is a one-stop shop; but my opinion is that offloading integration work to busybox is doing a disservice to the project. - The very fact that you are using the existence of the patch and diff applets as an argument in favor of the inclusion of make is *exactly* why creeping featuritis is so insidious and terrible. You're right, since we have patch and diff, why not add make? And, since we started so well on the path of development tools, why not add binutils, and a C compiler, and autotools, and git? Slippery slope is very, very slippery. We have a duty to recognize creeping featuritis for what it is when it happens, and I'm saying - loudly and unpleasantly because I don't like to be the one having to spend time on this - that this thread is pure unadulterated unchecked creeping featuritis, and every time a similar proposal is not met with a hard NO, the value of the busybox project decreases. Now, am I talking to software engineers, or do I really have to explain *why* the value of the project decreases with every useless additional applet, *even when* there is a configuration switch that can disable it at build time? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Sime makelike wrapper scripts support
Laurent you've put effort and heart to write that "funny" sketch Oh please, stop the flattery. I didn't proofread, I left in a few typos and grammar errors, and didn't even linewrap to 72 so it looks goofy in the archive. No, I put in the exact amount of effort that this thread is worth, i.e. extremely little. But I still put in *something*, because if nobody's speaking, people who suggest obvious ad-hoc creeping featurism might get the mistaken impression that's it's something totally normal and accepted in the busybox community, and that such things are worth discussing. I'm just dragging the window of discourse back to normal here. The biggest trolls aren't necessarily the ones who present themselves as such. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Sime makelike wrapper scripts support
Hey folks, I just had an idea today while crossing the street (please don't do this, it's dangerous, you may be hit by a car. It almost happened to me. It's a a good thing that I don't often have ideas!) I thought that I've always needed a small applet that takes user input from different clients and tallies the votes after a timeout. And I figured that everyone could benefit from it! Let's call it, for instance, "bikeshed", and let's say that users want to vote on the colour of the bikeshed. Every participating user could do something like: $ bikeshed pink or $ bikeshed green or $ bikeshed "blue with yellow stripes" and after some time, when several users have done that, you could call $ bikeshed results The majority of users voted for: sickly green with traces of blood! The concept is very simple, and the implementation could be very simple too, it just needs to fork a small server (bikeshedd) that listens to a Unix socket. See, I've thought about it! But I don't have the time or skills to work on an implementation, so I really cannot write myself. And can you imagine the amount of effort needed if I had to maintain it as a separate project? Even if it was a simple shell script, I would need to copy it on every machine where I need to use it! That's way too time-consuming. So it would be *totally awesome* if you could write a "bikeshed" applet for me, and add it to busybox. That way, everyone who needs it would be able to benefit from it automatically! Thanks a lot, -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 2/8] mdev: increase netlink buffer sizes
Overcommit is disabled: / # cat /proc/sys/vm/overcommit_memory 2 That doesn't mean overcommit is disabled. That means it's enabled with a hard limit. What was overcommit_ratio? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 2/8] mdev: increase netlink buffer sizes
The socket receive buffer turned out to be too small for real world systems. Use the same size as udevd to be on the safe side. As this is just a limit and the memory is not allocated by the kernel until really needed there is actually no memory wasted. Is it also the case when overcommit is disabled? busybox is used in a lot of embedded systems, and some of them disable overcommit. Committing 128 MiB would make mdev completely unusable. -- Laurent, who still believes leaving the choice to the user is the correct approach. https://skarnet.org/software/mdevd/mdevd.html___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: mdev -d can (silently) die with "read: no buffer space available"
OTOH udevd seems to use a whooping 128MiB for the netlink socket receive buffer. And the ENOBUFS error is exactly what should be returned if the receive buffer overflows. From experiments I made when writing mdevd (which is a standalone replacement for mdev), the netlink socket buffer needs to be surprisingly large compared to the total size of events that go through it, about 2 to 3 times the size of events. No, I don't understand it either, and I didn't go check the netlink code in the kernel to try and figure out what's going on. But I need 200 kB to comfortably handle a spike of events that's about 64 kB in total. (mdevd uses a default of 500 kB, and it's tunable on the command line.) So, it's not at all a surprise that udev, which doesn't care at all about small systems, uses 128 MiB. It's so it can coldplug every supported device in the Linux kernel at the same time, and survive the spike. XD Hmm, adding a stat() for each event that is processed does not seem right. In the normal case there will never be a mdev.log... mdev really should not log to its own file. It should log to stderr and let its logs be picked up by a dedicated logger, like every other correctly-written daemon. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: rustybox, an experimental fork written entirely in Rust
The busybox mailing-list has managed, for the most part, to stay clear of language flamewars during all these years. Of course, blips happen now and then. A few years ago, the fashionable language was Go, so inevitably, someone wrote "Gobox", because of course they did. For the most part, we nodded, and moved on. Gobox is still a thing somewhere; obviously it hasn't replaced busybox. It was just as inevitable that someone would come up with a busybox equivalent in Rust. The most surprising thing about it is that it took so much time: Rust is already old news by today's standards. Please just acknowledge and move on. Let rustybox be a thing. Don't let the thread devolve into a n+1th avatar of the "Rust vs. C" discussion, which can be found about anywhere on the Web (and that you can basically spark anywhere) if that's what you like. The reason why these takes don't stick has nothing (or very little) to do with the intrinsic value of alternative languages vs. C. The reason is purely operational. The main advantage of busybox compared to, say, GNU coreutils, is the ease of deployment. It's easy to build (you need a C toolchain and make, no other dependencies), it's easy to cross-build, it's easy to deploy (a single binary you can copy), it's easy to make a static executable, it's easy to bootstrap a rootfs from scratch when you have busybox. Those aspects are important in the embedded world, where busybox shines; the development cycle for a product that includes busybox can be *a lot* shorter than what it is with coreutils, and that's why it's used. (The thriftier RAM use is a nice point too, but clearly not the main reason nowadays.) Alternative approaches to busybox forfeit that advantage. Neither Go, nor Rust, nor anything else, comes anywhere close to C when it's about ease of deployment, and especially ease of bootstrapping. And that's really on the implementation of those languages, where ease of deployment, and especially ease of bootstrapping, has clearly not being seen as a design goal. It's a choice that has been made; there were certainly very good reasons for that choice; but an effect of that choice is that, no matter how "good" the language is, it is unsuitable for software such as busybox. It's not on the language design, it's not on "whether it can replace C or not" (it cannot, but not for language reasons). And it's not on the OP, who wanted to perform an experiment. The experiment has value, even if the result isn't something we would use. So, thanks OP, and please don't take it personally if the general reaction isn't what you wanted to see. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/3] mdev: add daemon mode
If mdev is used as kernel hotplug helper and the system generates many hotplug events it will quickly consume considerable resources because a process is forked for each event and, if the mdev.seq feature is used, they must also coordinate among each other. While the uevent applet mitigates some of the resource problems you still have to pay the cost for a fork/exec and parsing of mdev.conf for each event. Doing it that way spares the fork/exec indeed, but you're still parsing mdev.conf for every event. The parsing is done in make_device(), which is called at least once per event. And there's no way to prevent that - that's just how mdev is structured. To parse mdev.conf only once and have a really fast code path on event reception, you'd basically need to rewrite mdev entirely. Are you aware of https://skarnet.org/software/mdevd/ ? :) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: I cannot find latest binaries file(.exe file) of BusyBox
If it was built with dynamically linked glibc, though, would it really matter? busybox has no external dependencies other than, if dynlinked, a couple of standard support libraries (libc, libm, libresolv, libcrypt), so it should still work everywhere that has a more recent version of glibc than its build environment (and people who build redistributable binaries usually use the oldest glibc they can lay hands on, for exactly this reason). And that is a bigger and bigger requirement, because glibc is less and less ubiquitous. Having a busybox binary that's independent from glibc is interesting per se because its uses are not limited to environments that do provide glibc. And there are more and more distributions, even doing non-embedded, that do not use glibc - and there are even cases where it makes sense to run them in WSL. And there are also cases where it makes sense not to want to rely on the official prebuilt busybox binary. I'm not commenting on the rest of the discussion, because I have zero horses in the race, but I wanted to underline this point. Do not make judgments on other people's use cases. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question: Finding libraries that are required for busybox??
Using busybox nslookup failed due to one of the libraries I had removed not being there? libnss_dns and libnss_files. ldd busybox doesn't report these libraries are used? Once I put those libraries back, the nslookup resolves. That's because those shared libraries are not used at build time - or at process start time - so ldd cannot find them. They are actually dlopen()ed by glibc later in the life of the process, whenever you do an NSS request (which nslookup does). In the precise case of the libnss_*.so files, the way to know whether or not you need them is to look at /etc/nsswitch.conf : depending on how your NSS is set up, you may or may not need certain backends. In the general case, however, I don't think there's a simple way of finding out all the .so dependencies of a project whenever dlopen() is involved. You just have to know the project and what .so modules it may want to load dynamically. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Make busybox more portable part deux
Not all systems have SA_RESTART, but signal_SA_RESTART_empty_mask() is required to build busybox. This at least allows you to build on systems without SA_RESTART. SA_RESTART is POSIX, and supported at the very least on Linux, Free/Open/NetBSD, MacOS and Solaris. What system is there that busybox officially supports and that doesn't have SA_RESTART? If you want to support the absence of SA_RESTART, the patch you sent is insufficient anyway. For correctness, you would need to find all the places in busybox where signal handlers are installed and an interruptible libc function is called, and if the system doesn't have SA_RESTART, wrap those calls in loops to manually restart them on EINTR. It's the only way to ensure consistent behaviour. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup
When PID=0 in early kernel_init, PID=1 has a skeleton running, this detection is not the Busybox /sbin/init, but a place holder for when the real Busybox /sbin/init is do_execve'd Are you saying the kernel could spawn a /sbin/reboot process *before* kernel_init execs into the userspace init? If it's the case (and Denys' test will verify it), it's violently out of spec. There should be no other userspace processes present before init, and if there are, the behaviour is totally undefined, and things should very much be expected to fail. It is basically impossible to program under Unix if you cannot assume there is a pid 1 present that will reap zombies. It would be worth it to report the situation to the kernel maintainers so they make sure the spawning of userspace processes (triggered by soft-poweroff or anything else) is deferred until after /sbin/init has been do_execve()'d. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup
Even when process=1 is started, it still leaves a window when the signal handler setup has not been completed. Yes, but you can still use kill(pid, 0) to check whether init is ready to receive signals: doublefork a zombie and repeatedly kill it with signal 0. When you get -1 ESRCH, it means init has reapt the zombie, so it's in its reaping loop, and at that point you know it has installed its signal handlers. See http://lists.busybox.net/pipermail/busybox/2017-October/085888.html That's arguably uglier than using abstract sockets, but it can be done without modifying the init code at all. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] init: Add handshake to poweroff/reboot for signal handler setup
+ fdrc = connect(fdBB2, + (struct sockaddr *)_addr2, + sizeof(sa_family_t) + + BB_SIGNALS_SOCKET_STR_LEN); + if (fdrc == 0) + break; This will not work, because connect() will not succeed if the server does not listen(). And you cannot listen() in init without significantly rewriting its execution flow. However, you can still use this: connect() on an unbound socket will return -1 ENOENT, connect() on a bound socket that is not listening will return -1 ECONNREFUSED. So if you change your fdrc test to an (errno == ECONNREFUSED) test, it should work. See http://lists.busybox.net/pipermail/busybox/2017-October/085893.html and the whole surrounding thread. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.
Zombies will _always_ be observable, even if you try to reap immediately. Of course. I used "observable" in the broad sense, meaning there is a nonzero amount of time where init is not runnable, won't be scheduled, and won't immediately reap zombies. This makes zombie observation literally millions of times more likely than when there's no blocking path between the moment it gets a SIGCHLD and the moment it reaps the zombie. :) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.
How about this: IIUC, this changes init's behaviour to only sleep after it has just started a direct child, so as long as the /etc/inittab processes are stable, it will always reap distant orphans instantly; but it will still wait for 1 second before reaping a batch of processes that died at the same time it spawned a getty or something. Am I correct in my understanding? If I am: this reduces the number of cases where the window is hit, so it will certainly help; zombies will only be observable in some corner cases. However, this does not eliminate the behaviour entirely, it only makes it more rare - and more obscure. You _know_ that at some point someone is going to hit it and will get headaches trying to understand what is happening. I have no strong opinion on whether this is an overall improvement or not. It probably is, because /etc/inittab processes do not change often, so it makes the window really tiny. If you're not willing to go the (best, but more complex) route of maintaining a separate minimal respawn date for each of init's direct children and restructuring the reaper loop, I think the most important improvement would be a comment in init.c explaining why the zombie apocalypse may happen in what circumstances, and that it will only last one second. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.
It depends whether you consider init to be required to reap zombies as fast as possible. I don't see that as a requirement (so far, feel free to convince me otherwise). I don't see it as a hard requirement either; I don't really mind having zombies around for a few seconds, provided they eventually get reapt. However, most people are used to the sysvinit behaviour, and rely on it. Few people are aware that bb init may wait for one second before reaping zombies, because the window is not hit often, only bb init does that, and bb init is not as common as other inits. So it's a peculiarity that people do not plan for, and it may bite them. The javascript test I mentioned failed on Alpine Linux because it hit the one second window; the test was incorrectly designed, but it worked with basically every other init out there. The current thread's OP observed zombies when killing runsvdir, which led him on a red herring chase, a misguided patch, and wasted time in this thread. I'm personally not impacted, because I have my own pid 1 (s6-svscan) which reaps zombies as soon as they happen; and stricto sensu, I don't think bb init's behaviour is a bug. But changing it to mimic the behaviour of all the other inits would certainly prevent similar annoying, if minor, problems from arising in the future. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Fix runsvdir so it reaps children and avoid zombi processes when killed.
Without this fix it will create zombies that might cause deadlocks No. On December 23rd, when you sent a message to the list describing your issue, I sent a reply, the first reply you received, explaining what was happening to you. Did you read it? Did ANYONE read it? Or is the thought of "the problem comes from busybox init" too uncomfortable? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question regarding runsvdir not reaping children.
What is the rationale behind not reaping the children when the program exists? i run it from inittab as a respawn process and I get zombies when killing it when not reaping children alas the fix was pretty simple. Unless you're running runsvdir as process 1, there's no reason to do so, because on runsvdir's death, its children will be reassigned to init, and init will reap those zombies. If you're getting zombies when killing runsvdir, then you have another problem, that is unrelated to runsvdir. Note that busybox init sometimes takes one second to reap zombies (which is what you may have observed). This is a flaw in the design and cannot be fixed without significantly rewriting it, but it should not matter for practical purposes - zombies hanging around for one second is generally not an issue. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[announce] mdevd - a mdev-compatible uevent manager
Hello, About two years ago, there was some talk on the Busybox mailing-list about the need for a version of "mdev" that would not use a separate process for every uevent (as a hotplug manager does) but that would act as a daemon, able to handle a series of uevents - typically read from the netlink. One of the goals of such a program was to reduce boot time on slow / resource-constrained devices that don't like creating hundreds of processes at the same time - especially when they contend for a sequence number. I took a quick look at the time, but came to the conclusion that the way mdev was coded made it very difficult. Basically, mdev gets its uevent variables from the environment, then reads and processes its config file, performing actions as it goes. A quick hack to add "daemon mode" support to mdev would still make it process the config file for every event, similarly to what "mdev -s" does; this would remove the forks but still be pretty inefficient, not to mention particularly ugly. To implement "daemon mode mdev" in a clean way, a full rewrite was needed. So I shelved the idea at the time. Until now. mdevd is a uevent manager reading a sequence of uevents and handling them without forking, that understands the full /etc/mdev.conf format. "mdevd-coldplug | mdevd" is equivalent to "mdev -s". "mdevd-netlink | mdevd" is a daemon that listens to the netlink and processes uevents sequentially, without the need for mdev.seq hacks coming from the kernel spawning hotplug managers in parallel. You can find it here: https://skarnet.org/software/mdevd/ git://git.skarnet.org/mdevd https://github.com/skarnet/mdevd Since it's a full rewrite with a very different architecture from mdev and little code reusability with the rest of Busybox, it did not make sense to include it in Busybox, which is why it's provided as a separate package. Bug-reports welcome. mdevd is still considered beta for some functionality I could not extensively test, such as firmware loading. If your setup uses firmware loading or otherwise obscure mdev features, I'm especially interested in your reports and/or comments. (mdevd comes with a dry run mode, so you don't have to be a reckless cowboy to test it.) Enjoy, -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Race in reboot/poweroff path at init?
That's OK, as the helper (/sbin/poweroff) has the opportunity to retry if the connect() fails (because init hasn't established the listening socket yet). The main difference is that the sender can detect failure, and retry if necessary. AF_UNIX sockets in the abstract namespace don't require a path bound to the filesystem, so perhaps they would be available early enough - or have I missed something there? That is true, I hadn't thought of abstract sockets, and it would work. However, changing the way poweroff signals init is a big change, and in particular, making init listen to a socket is very significant: you know need to multiplex reaping zombies with listening to connections. It's not hard, but it requires patching init significantly, reworking its control flow around an asynchronous event loop; and at that point you're just better off using a better pid 1 process (such as s6-svscan, which already does this - have you considered switching inits? ;)). And changes of that magnitude are pretty dangerous - I'm quite convinced there are some people relying on the "send a signal to init" mechanism and whose systems would break if that mechanism were changed. The "send a signal to init" mechanism is a good one, and does not fundamentally need to be changed; your problem is a readiness detection one, i.e. whatever mechanism you're using to tell init to shutdown, you can't use it before init is ready to handle it. And that's where abstract sockets can be useful: you can use abstract sockets as a simple synchronization mechanism. The easiest way to do it would be: when init has installed its signal handlers, it creates an abstract socket (close-on-exec, of course) and binds it - but does not listen to it and does nothing else with it). And poweroff checks for the presence of this socket by repeatedly attempting connect(). When errno changes from ENOENT to ECONNREFUSED, it means the socket has been created and init is now ready to receive signals. This requires minimal change to init and a small polling addition to poweroff - which I think is much better and safer than a heavy change to busybox's init. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Race in reboot/poweroff path at init?
There's the sigqueue() mechanism out there. From the man page, it seems it's essentially dedicated to send data together with the signal, but it also has a queueing mechanism implemented in the kernel. Wether this allows the message to be kept in the queue until the destination process unmasks it, this isn't written explicitely in the man, but maybe somebody knows it. Anyway your case is a perfect test bench. From what I understand from the POSIX page for sigqueue(), it only makes a difference if the receiver has already installed a signal handler with SA_SIGINFO. If the receiver hasn't installed a signal handler yet, the signal just gets delivered as is. So it's not a mechanism that can be used to defer signals until the receiver has installed a signal handler. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Race in reboot/poweroff path at init?
- using a synchronous channel to send the shutdown/reboot message between the poweroff/reboot helpers, rather than an asynchronous signal. Say, have init listening on a socket, allowing the poweroff binary to wait and/or retry. That would not work either: you could receive the event before init starts listening to the socket. There will always be a window where init can't receive events. The kernel starts it barebones, with no channel of communication to other processes; if an event arrives before it starts establishing these channels, you're out of luck. The best you can do is make the window as small as possible. If you need to be 100% safe, then you need to somehow queue the events before init starts processing them. But that's tricky, because it's extremely early - you have nothing but the kernel and the /sbin/poweroff process' memory. You don't even have the guarantee that you can write to a filesystem: you only have the rootfs and it may be read-only. You don't even have a tmpfs yet. You can't be certain you have a devtmpfs mounted. You don't have /dev/shm. You don't have /proc. So it's a matter of finding a way to queue events that don't involve writing to the filesystem at all. That severely restricts your options: for instance, POSIX message queues sound like a perfect fit, but Linux implements them via a virtual filesystem that needs to be mounted first, so it's a no-go. Signals are actually pretty good: all they require is that init has installed a handler, which can be done early. The only issue is that you can't queue them. What I would do is add a check to /sbin/poweroff that init has progressed to a point where its signal handlers are installed, and if it's not there yet, poll until it is (i.e. sleep and retry). What check to use? well at this point it's very hackish. The only thing I can think of that doesn't depend on the contents of /etc/inittab is that when init reaps zombies, we know it has its signal handlers installed. So... I would have poweroff doublefork a process (have the child communicate the pid of the grandchild before dying), the grandchild dies - at this point it's a zombie waiting for init to reap it - and poweroff repeatedly hits the grandchild with kill(), using signal 0 just to be safe. When kill() fails with ESRCH, it means the zombie has disappeared and init is now ready to accept signals. It's really ugly, but it's the best I can come up with that makes no unsafe assumptions. Whether implementing that in /sbin/poweroff is better than simply eating the race condition... that's your call. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ls: fix support for long options when FEATURE_LS_COLOR is deselected
(replying to myself because for some reason the busybox ML manager does not send me the mails in a whole thread if I've been Cc:ed in one of the messages in the thread. So now I need the Cc: every time. ISTR it's a classic misfeature of Mailman.) Xabier Oneca: > Shouldn't "--color" be guarded by IF_FEATURE_LS_COLOR, then? As I understand it, it's a choice: if a feature is not selected at build time, guarding the option declaration in applet_long_options makes busybox fail when the option is given at run-time, whereas not guarding it (i.e. always declaring the option) makes busybox silently ignore it. Both approaches are justifiable. Since neither --full-time nor --group-directories-first appeared to be guarded (by FEATURE_LS_TIMESTAMPS and FEATURE_LS_SORTFILES respectively), I chose to stay as close as possible to the existing code and not guard --color either. The syntax of getopt32() is not exactly intuitive to say the least. I wonder what benefit it brings over getopt() and getopt_long(). Denys, any insights? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] ls: fix support for long options when FEATURE_LS_COLOR is deselected
Declaration of ls_longopts and initialization of applet_long_options were incorrectly guarded with ENABLE_FEATURE_LS_COLOR; that yielded a "ls: NO_OPT: \xff" error message when long options were selected and color support was not. This patch ensures long options are initialized separately from color support. --- coreutils/ls.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/coreutils/ls.c b/coreutils/ls.c index 6e0a52d75..50aaf132c 100644 --- a/coreutils/ls.c +++ b/coreutils/ls.c @@ -1067,11 +1067,6 @@ int ls_main(int argc UNUSED_PARAM, char **argv) * 'auto', 'tty', 'if-tty' * (and substrings: "--color=alwa" work too) */ - static const char ls_longopts[] ALIGN1 = - "full-time\0" No_argument "\xff" - "group-directories-first\0" No_argument "\xfe" - "color\0" Optional_argument "\xfd" - ; static const char color_str[] ALIGN1 = "always\0""yes\0""force\0" "auto\0""tty\0""if-tty\0"; @@ -1079,6 +1074,13 @@ int ls_main(int argc UNUSED_PARAM, char **argv) const char *color_opt = color_str; /* "always" */ #endif +#if ENABLE_LONG_OPTS + static const char ls_longopts[] ALIGN1 = + "full-time\0" No_argument "\xff" + "group-directories-first\0" No_argument "\xfe" + "color\0" Optional_argument "\xfd" + ; +#endif INIT_G(); init_unicode(); @@ -1091,7 +1093,7 @@ int ls_main(int argc UNUSED_PARAM, char **argv) #endif /* process options */ - IF_FEATURE_LS_COLOR(applet_long_options = ls_longopts;) + IF_LONG_OPTS(applet_long_options = ls_longopts;) opt_complementary = /* -n and -g imply -l */ "nl:gl" -- 2.13.0.90.g1eb437020 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox httpd sends output of stderr to the Website
https://www.freebsd.org/cgi/man.cgi?query=inetd "Theserver program isinvokedwith the service socket as its standardinput, output and error descriptors" Show me an implementation of inetd which does not do this. Oh, I'm not pretending wikipedia is wrong. I was just amused by your choice to quote it (as opposed to, for instance, the FreeBSD man page for inetd that you now quoted). And my main point here is that it's a suboptimal design choice, and for that reason and others, tcpserver should be preferred. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox httpd sends output of stderr to the Website
Unless they do want _remote user_ to see the message.
For example, if you start a shell over a tcp connection
("poor man's telnet"), you do want to see shell error messages
when you work in that shell, right?
IOW: inetd can't know which behavior is desirable, since both make
sense.
So the best thing is to follow the existing established practice
(if it exists). I googled for it and there is a somewhat weak
indication
that inetd's of various Unixes did send stderr to the socket.
Even wikipedia says:
"...
inetd hooks the sockets directly to stdin, stdout and stderr
of the spawned process"
Ah, wikipedia, that famous normative specification site. ;)
Note that if stderr is not automatically redirected to the client,
it is easy for a service to do so if it wishes: run
"sh -c 'exec foobard 2>&1'" instead of "foobard".
And if the service does not want stderr redirected, then it has nothing
to do - the infrastructure running the service is in charge of sending
stderr to an appropriate logging place. This is the behaviour of
tcpserver
with a supervision suite such as s6 or runit, where the supervision tree
also manages a logging chain and services can do what they want with
their stderr - redirect it to the client, get their own logger, or just
let the supervision tree handle it (i.e. send it to the default system
logger).
Whereas if stderr is automatically redirected to the client by the
superserver (which is the case with bb's inetd), then everything's fine
as long as all services want that behaviour, but if a service does *not*
want its stderr redirected, what should it do? There is no "let the
infrastructure handle it" option. The service has to choose a place for
its stderr to go, and the choices are bleak: /dev/null, a log file
(which can grow uncontrollably), or a fifo to a previously defined
logging program that cannot take advantage of the superserver model and
that the inetd service is silently relying on. That's more brittle, and
more work for the administrator.
I really recommend not using inetd and spawning a tcpserver process
instead for every inetd-mode service you have. It is much more
comfortable
to admin in the long run.
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox httpd sends output of stderr to the Website
inetd is tying stdout and stderr together. Personally I think this is wrong since it generally means that inetd services must be careful never to write to stderr. Use tcpserver instead of inetd. It allows you to use the "inetd mode" in applets, and does not exhibit the problems that inetd does. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: crond and syslog
not sure what the DGRAM socket corresponds to… On Linux /dev/log is normally implemented as a SOCK_STREAM socket, so I suspect it’s not that. It is likely that. There is no standard at all for the nature of /dev/log, it all depends on your syslogd. Old versions of syslogd created /dev/log as SOCK_STREAM; loggers such as rsyslogd now create it as SOCK_DGRAM by default. socklog uses a SOCK_DGRAM, I believe; s6's implementation of syslogd uses a SOCK_STREAM. Client-side, glibc supports syslog() writing to a SOCK_STREAM as well as a SOCK_DGRAM. uClibc is the same IIRC. musl only supports writing to a SOCK_DGRAM for now (unfortunately - but this will change some day if I take the time to make a good case for SOCK_STREAM support). Why would LOG_CONS be selected unconditionally? Shouldn’t that only be selected if (opts & OPT_f) ? No, this is tradtional historic behaviour. Most programs that use syslog() default to sending their logs to /dev/console when they cannot reach syslogd - no matter whether they're running in the foreground or not. "Running in the foreground" is the correct way to start services anyway, when using a supervision system such as runit, s6, or even systemd - so the presence or absence of the "-f" option should have no impact on the way logs are managed. What is happening here is that your syslog client (crond) does not manage to talk to your syslogd, and so syslog() falls back on sending its data to the console. The fallback is normal; the problem happens earlier. You could strace crond in order to see where and why syslog() is failing to reach syslogd, and proceed from there. If you're using musl, it's possible that your syslogd is set up to create /dev/log as SOCK_STREAM, and musl opens it as SOCK_DGRAM, which works because Linux is permissive on that, but fails later on when syslog() tries to write. In that case you should find the option in syslog-ng to make syslogd listen to a SOCK_DGRAM, or join me in lobbying the musl author for SOCK_STREAM support in syslog(). :) Also, unrelated: I'm not sure how OpenWRT is supposed to be built, but generally speaking it's unusual to have C programs depend on libgcc_s.so; libgcc is normally linked statically, and only C++ programs require the dynamic version. Unless it's a deliberate design choice in OpenWRT, you may want to investigate how your toolchain is made. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] httpd: fix address family for reverse proxy client socket
When httpd proxies a request to another server, it first creates an AF_INET socket, then resolves the server name to a sockaddr, then connects to it. This fails if the server name resolves to an IPv6 address. This patch ensures that the socket is created with the correct address family (AF_INET6 if the server resolves to an IPv6 address and AF_INET otherwise). --- networking/httpd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/networking/httpd.c b/networking/httpd.c index d301d598d..cfcd2a06e 100644 --- a/networking/httpd.c +++ b/networking/httpd.c @@ -2396,12 +2396,12 @@ static void handle_incoming_and_exit(const len_and_sockaddr *fromAddr) int proxy_fd; len_and_sockaddr *lsa; - proxy_fd = socket(AF_INET, SOCK_STREAM, 0); - if (proxy_fd < 0) - send_headers_and_exit(HTTP_INTERNAL_SERVER_ERROR); lsa = host2sockaddr(proxy_entry->host_port, 80); if (lsa == NULL) send_headers_and_exit(HTTP_INTERNAL_SERVER_ERROR); + proxy_fd = socket(lsa->u.sa.sa_family, SOCK_STREAM, 0); + if (proxy_fd < 0) + send_headers_and_exit(HTTP_INTERNAL_SERVER_ERROR); if (connect(proxy_fd, >u.sa, lsa->len) < 0) send_headers_and_exit(HTTP_INTERNAL_SERVER_ERROR); fdprintf(proxy_fd, "%s %s%s%s%s HTTP/%c.%c\r\n", -- 2.11.0.rc2 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: potential error with adduser
I was more or less surprised by the fact that the default method was to put false information in the passwd file and was clarifying if this was appropriate. As I've stated numerous times, I can't see a circumstance where this would be advised. It's very traditional to put nonsense information in /etc/passwd in the fields where that information is irrelevant or non-applicable. For instance, for a system account, you often have a meaningless gecos, an "x" password, and /nonexistent (some people prefer /bin/false) as login shell, since nobody's ever supposed to log in as those users. The idea is to make the login process instantly fail, or the information retrieval process obviously show that something went wrong and that information wasn't even supposed to be retrieved. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Current git HEAD busybox segfaults on some applets
Here's my suggested fix - as unintrusive as possible. -- Laurent 0001-Only-use-nonstandard-unlocked-line-ops-when-we-re-ce.patch Description: Binary data ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re[2]: Current git HEAD busybox segfaults on some applets
A full gdb output is available here: http://pastebin.com/3k6SENiX The issue comes from the fact that fflush(stream) is #define'd as fflush_unlocked(stream), so fflush(0) actually runs fflush_unlocked(0), which segfaults with the current version of musl (but not glibc). fflush_unlocked() and friends are not part of the standard API (only getc_unlocked and putc_unlocked are) and it is a mistake to assume they 1. exist, 2. behave the same as their non-unlocked counterpart. The culprit is this commit: https://git.busybox.net/busybox/commit/include/libbb.h?id=aa3576a29b9619f4e1c1b131f5db53ad2bc2cb00 Later commits modify the additions in libbb.h, but those additions are incorrect in the first place. I will send a patch that removes them. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Current git HEAD busybox segfaults on some applets
On 15/09/2016 13:55, Denys Vlasenko wrote: Works for me... I can reproducibly segfault when wgetting a page twice (i.e. the file already exists). I can also reproducibly segfault when using busybox vi, for instance on the index.html file downloaded with "wget http://skarnet.org/; I have tried building with 2 different toolchains that have always worked for me, including with previous versions of busybox, and both binaries segfault. Linux-4.6.3, musl 1.1.15, x86_64. I will try on another machine. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Current git HEAD busybox segfaults on some applets
Hello, The current git HEAD of busybox (1.26.0.git today) segfaults when some applets are invoked; at least wget and vi are impacted. The failing config is here: http://skarnet.org/tmp/bbconfig.txt I don't have time right now to look for the problematic commit, but a version from last April or so was working for me, 1.25.something. I still have the buggy binary, I can say whether or not a given applet segfaults if it can help someone narrow it down. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] chpst/setuidgid doesn't support multiple/supplementary groups
On 06/09/2016 20:59, Deweloper wrote: My proposal is to change the interpretation of chpst's -u option a bit: This would deviate from upstream runit's semantics. Your idea is valid, but I think you should submit it to upstream runit first, because creating incompatibilities between the original implementation and the busybox implementation isn't a good thing. In the meantime, shameless plug: the equivalent s6 utilities achieve what you want with supplementary groups, namely http://skarnet.org/software/s6/s6-applyuidgid.html which can be prepended with http://skarnet.org/software/s6/s6-envuidgid.html -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] libbb: More informative "short write" error
On 06/09/2016 04:04, Kang-Che Sung wrote: Um, excuse me, but may I suggest a more informative message than "short write"? "Short write" is a little bit unclear. "Short write" is the standard technical denomination for that issue; using another term would be confusing. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] libbb: More informative "short write" error
On 04/09/2016 12:11, Lauri Kasanen wrote: Over at TinyCore, we receive a huge number of questions of the type "I got "short write", what does it mean?". Mostly for the rpi port and when using bb wget. The attached patch makes the message more informative, and hopefully lets more people know what's up without having to ask. I think a better fix would be to have a version of bb_verror_msg() (which is called by bb_error_msg_and_die) that adds strerror(errno) to the printed message. This way, the information given would always match the actual error that happens. Of course, it's more invasive. But bb_verror_msg() deserves to be rewritten anyway: it performs a lot of operations that can fail, including allocating heap memory - you don't want that on an abnormal exit path. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] udhcpc: perform_release(): Unconditionally call deconfig script
On 26/08/2016 18:53, Denys Vlasenko wrote: However, a more robust solution is to have process babysitter to run some cleanup script. Imagine that udhcpc is killed with SIGKILL. Can't handle that easily inside udhcpc... Does the cleanup script need to be run every time udhcpc dies? A process supervisor can run a finish script that knows the exit code of udhcpc, or the signal that killed it, but if there are moments when you _don't_ want to run the cleanup script if udhcpc receives a SIGKILL, then it's more complicated. A supervisor can only know how the service died, it cannot know the state the service was in when it got killed. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: make menuconfig deps
Kbuild, be it the kernel's or busybox, assumes that ncurses is available in /usr or /usr/local, and nowhere else. To override those assumptions if your ncurses package isn't installed in a "standard" location, you need a few workarounds, as in manual make variables. My hand-built ncurses is installed in /opt/ncurses (.../include and .../lib). For it to be found, I invoke make menuconfig this way: make menuconfig \ HOST_EXTRACFLAGS='-I/opt/ncurses/include -DKBUILD_NO_NLS -DCURSES_LOC=""' \ HOST_LOADLIBES='-L/opt/ncurses/lib -static -lncurses' Yes, that's HOST_LOADLIBES with an 'E'. Replace /opt/ncurses with the full path to your ncurses installation. Feel free to remove -static if you're using glibc and/or don't mind configuring your dynamic linker so that it knows how to find your libncurses.so library. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] getrandom: new applet
On 12/07/2016 23:53, Rich Felker wrote: There are very good reasons it's a syscall rather than a device: many use cases require a never-fails entropy source, and with the device node approach they're vulnerable to fd-exhaustion attacks. Most existing bad code, when faced with such a situation, falls back to some completely insecure seed like time(). The only reliable way to prevent such idiocy was to provide an interface that can't fail. But what exactly is getrandom() going to do for existing bad code? If the answer is "bad code should be patched", then bad code could (and should) also be patched in the absence of getrandom() - for instance, to replace the insecure fallbacks with better ones. getrandom() makes the patch easier for sure, but it's not stricto sensu *needed* for that case, unless there's just no way to get a good seed without kernel help. Oh well. Now that it's here, I guess it's nice that we have a random source that just cannot fail. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Was examples/var_service useful for anyone?
My unpopular but firm opinion is that existing supervision suites (be it runit, s6, perp or even daemontools(-encore)) are already lightweight enough, and easy to build and install on embedded environments for people who want them, and that reimplementing them is more trouble than it's worth and outside the scope of busybox. Even if you insist on having runit commands inside busybox, you could simply refer people to the official runit documentation. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] getrandom: new applet
We could say that waiting 6 minutes (using /dev/random) instead of 3 minutes (using getrandom()) is acceptable, but now what if you have 10 soft wanting to do that, /dev/random might block again This thread is a dialogue of the deaf and a strawman burning fest, and if you keep thinking the other party is a noob, keep assuming the problem is that they're not properly understanding what you're saying, and keep providing the same references that they know by heart, you will get nowhere very fast. The real issue here is that getrandom() introduces a behaviour that is *not* obtainable by the filesystem API. Arguably, it's the correct behaviour, yes; but it still requires the system call - and thus, a new applet. And historically, the filesystem API (i.e. writing to / reading /dev/random and /dev/urandom) was supposed to be _all that userspace needs_ to get random data. So the question is, why the heck isn't it possible to rely on the filesystem API to get the correct behaviour? Why are there two separate entropy pools for /dev/random and /dev/urandom? If there were a single, shared, entropy pool, I could read a character on /dev/random, and when I get this character, it means there's enough entropy and then I can read /dev/urandom for the rest of the lifetime of the system. Since the entropy pools are separated, and /dev/urandom never blocks, then I have no simple filesystem API to block until /dev/urandom gets properly seeded. As you say, I have to rely on the getrandom() system call to do this. This is bad. This goes against the current (and, IMHO, desirable) trend of privileging filesystem APIs over system calls. Applications should be able to just read /dev/urandom and not care about all this. (Except in the case of fd exhaustion, but applications that use randomness should reserve a fd for /dev/urandom opening, and system-wide fd exhaustion is a rare issue - and if it happens to you, getrandom() isn't going to save you, the issue will manifest at some point later.) So, I would say the right thing is to run getrandom() once, in the machine's init scripts, and make sure that all applications that use /dev/urandom are only run after the unique getrandom() invocation returns. Yay, a system call that is meant to be used *once* in the lifetime of the machine. Of course, new applications can be written using getrandom()... if they forsake portability, thanks Linux. All in all, I think your applet is useful, yes. But it is useful *once*, at boot time; and if Linux cared to refactor the way it handles entropy, so that /dev/random could be used to block until /dev/urandom is safe, then your applet (and also getrandom(), because screw fd exhaustion) would not be needed at all. In theory I'd rather fix the problem where it lies, i.e. in the kernel, but in practice it would imply bringing that up on lkml and wasting a few months on bikeshedding for a very uncertain result - so instead, as much as I loathe it, adding a bugware applet to Busybox is a lot easier. Everybody now knows exactly what it's about, so please, stop splaining (and others, myself included, stop flaming); and let Denys arbitrate. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] devmem: support more than 4GB of physical memory on 32 bit systems
On 30/06/2016 13:24, Robert Schiele wrote: - off_t target; + off64_t target; http://stackoverflow.com/a/3221920 If you need 64-bit types, compile your programs with -D_FILE_OFFSET_BITS=64, which should be the default on reasonable systems (not sure how common reasonable systems are nowadays though). Please don't use the foobar64_t types, which are a very ugly piece of glibc bugware and make the code actually incorrect on 32-bit machines. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] getrandom: new applet
On 29/06/2016 00:37, Etienne Champetier wrote: Or everyone can switch to getrandom() because that's the right way The solution I am suggesting: - works today and is extremely easy to implement. - does not require patching busybox. - will work on every Linux kernel on the planet, not only new ones with getrandom() support. And you *will* find old kernels out there. - does not require porting/patching applications if they are currently using /dev/urandom. "The right way" had better be very right in order to be righter than that. (If your dd copies more than one byte when you give it count=1 bs=1, it's a bug. Can you send a strace?) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] getrandom: new applet
On 29/06/2016 00:10, Etienne CHAMPETIER wrote: first user of this applet will be LEDE (OpenWrt) to save an urandom seed using getrandom() (so we are sure /dev/urandom pool is initialized) That, or you could simply "dd if=/dev/random of=/dev/urandom bs=1 count=$blah" at boot time, in the background with something watching the PID. And those special snowflake services that need their precious, precious entropy can wait until the dd is dead before starting. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: busybox 1.25 ntpd retry initial DNS resolution (forever, no timeout for now).
On 28/06/2016 20:19, KP.Kirchdoerfer wrote: With busybox 1.24 ntpd fails to start and the boot process continues up to a shell login - allowing me to configure, start diagnostics and resolve errors. With busybox 1.25 ntpd seems to loop forever if now NTP servers are found, blocking the boot process and I never get a login to solve a possible pb or to do a first time configuration. Any hints how this can be solved? There is no reason why your access to a getty/login should depend on the launch of a NTP daemon. Your rc system apparently starts services sequentially, with a getty after the network: this is a misdesign that leads to the failure you're experiencing. Service managers should be able to parallelize service startup; most don't, but at the very least distros that use sequential service managers should start at least one early getty, for users to still be able to log in if something fails in the boot sequence. No matter what busybox ntpd does, it would be a good idea for you to make sure you have a functional getty very early in the boot process. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/2] Allow BusyBox to be built without a list of applet names
The lookup hash isn't collision-free: more than one input string points to the same applet. Normally invalid applet names might cause an unexpected one to run And this should be a GoodThing (TM) ? I'm inclined to vote against this change, because even if the risk is minimal, and even if hashing has important gains, it's just not worth it to change a correct, working mechanism to an incorrect one. Also, "rwok" is a cool name for a command. Somebody should add a "rwok" applet. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Be consistent with pkg-config usage
On 08/04/2016 05:59, Mike Frysinger wrote: keep in mind that PKG_CONFIG is a tool for the *host*, not for the *build*. so mixing it in this way is almost assuredly wrong. much like there is a HOSTCC var, you'll probably want to introduce a HOST_PKG_CONFIG var, and then change these files to leverage that. I don't understand. PKG_CONFIG is a build tool producing arch-independent output. So it always runs on the *build* and it makes no sense to have a host-dependent version of it. To tell pkg-config that it should look for host data instead of build data, a special PKG_CONFIG_PATH should be crafted with the locations of the host .pc files, and PKG_CONFIG_SYSROOT_DIR should be set to the host staging directory. Certain kernel Makefiles using PKG_CONFIG include the following line: PKG_CONFIG = $(CROSS_COMPILE)pkg-config I can only assume that when cross-compiling a kernel that needs those features, users create a $host-pkg-config script that sets the appropriate PKG_CONFIG_PATH and PKG_CONFIG_SYSROOT environment variables before executing the real, "native", pkg-config. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/2] ntpd: retry name-resolution until success
On 11/02/2016 13:34, Bastian Bittorf wrote:
with OpenWrt there is a feature where you have a "protected" area
in RAM which is not lost during reboot and used for having a crashlog
safed over a reboot. ("crashlog.o") see e.g:
https://dev.openwrt.org/browser/trunk/target/linux/generic/patches-4.4/930-crashlog.patch
we have extended this for always keeping a good timestamp over reboot.
Eh, that's nice, but as much as it makes sense for a crash log - where the
device is not powercycled - it's only a partial solution as far as the
clock is concerned: keeping a reasonable clock value across accidental
reboots is good, but...
ofcourse this does not work with a cold reboot.
... this. When the user powercycles the device, which hopefully happens
an order of magnitude more often than an accidental reboot, another
workaround still needs to be found.
Thanks for the info, however. It's interesting.
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 0/2] ntpd: retry name-resolution until success
On 11/02/2016 12:44, Denys Vlasenko wrote: In practice it is impossible to make daemons 100% robust. Because of this, we have several generations of babysitting tools which restart daemons on exit. I don't think it's the correct argument. Supervision tools should not be an excuse to be complacent with robustness. However, in this particular case, I agree with the exiting behaviour: the DNS resolution is only happening at start time, the daemon has not entered its loop yet, so there's no state to maintain and waiting would simply defer readiness. I think exiting is the correct thing to do when an error happens before the daemon is ready. That's utterly broken. You end up with an invalid or badly-wrong clock for the first 20 seconds after boot, which could lead to all sorts of problems with timestamps. You can't make your boot dependent on clock being set early. What if your network init always takes ~2 minutes? This is the case on my home DSL modem: DSL line training is that slow. I would love to have more input on this. My experience agrees with Denys here: system clock initialization that depends on the network is hard, because the clock may be incorrect until the network (and the time synchronization daemon) is up. This is not a real issue for machines that have a battery-powered hardware clock: the system clock can be set from the value of the hardware clock early at boot, and should be accurate enough for the boot process until the network is up. When there's no battery-powered hardware clock, however, I haven't found a good solution for the early boot. The system clock *will* be wildly inaccurate for some time. - It can be made "reasonable" by writing the system clock's value at shutdown time and reading it back at boot time. However, for devices with a read-only rootfs, this requires reading a value from a writable filesystem, which is not necessarily mounted early in the boot process. So there is still a part of the boot process, up until the correct filesystem is mounted, that has a wildly inaccurate system clock. This is not a complete solution. - For now, my solution is to set the system clock to an arbitrary, "close enough" value at the very start of the boot process. This ensures logs are not filled with nonsense values such as 1970-01-01. However, it does not guarantee monotonic timestamps from one boot to the next one: the early boot process, up until the mounting of read-write filesystems and the reading of the old value of the system clock, will still have incorrect, duplicate timestamps. This can be mitigated to an extent by getting the filesystem containing the latest saved system clock value mounted ASAP, but I have not found a perfect solution: the catch-all logger, as well as other early daemons such as udevd or equivalent (which the action of finding and mounting filesystems depends on), will still be started with a system clock that does not have unique values. I wonder if there are better solutions. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: AW: why are init's arguments wiped ?
On 01/02/2016 08:12, dietmar.schind...@manroland-web.com wrote: Anyone doing engineering work should come up with a better reason than something like "that's always been done that way". Oh, definitely. But I'm not the one engineering something here, I'm the bad guy saying I don't like the suggested change. History and tradition *are* valid objections to change, because breaking compatibility (if only compatibility of visual output) has a cost. They're not powerful objections: if a historical design is bad, and the new design brings obvious benefits, then it's entirely worth deviating from tradition. But everything else being equal, if the new design isn't strictly more powerful than the old one, then tradition may be worth keeping. In the present case, the choice is between "wipe init arguments" (historical) and "allow init to take arguments" (suggested change). Advantages of the historical behaviour: clean ps output Advantages of the suggested change: passing of information in the init arguments via /proc/1/cmdline Given that /proc/1/cmdline is not a standard Unix way of passing information, and that the OP's program would thus *only* work with the new-and-modified busybox init under Linux, making this change nothing more than a hack; Given that Unix already provides plenty of ways to pass information from a process to its scions, and that the command line is only such a way for programs specifically designed to perform chain loading, which init is not; Given that I have suggested an *easy*, safe, portable and perfectly Unix-ish way of accomplishing what the OP wants without having to patch anything; Therefore, in this precise case, I don't think the change is worth it. Seriously. Accusing *me* of following historical behaviours for the sake of it. :D -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: why are init's arguments wiped ?
On 29/01/2016 08:27, Nicolas CARRIER wrote: Even if I'm using linux, I want the solution to work in the context of init being launched as a pid 1 of a pid namespace, which is my main use case. In this situation, the kernel's command line can't be changed as it's the one of the host PC. But then the solution is easy: start your pid 1 as a script that takes arguments, does what you want with them, then executes into init. The "init" program is nothing magical. It's one of a thousand alternatives that are suitable for the traditional "duties of init" (does not die, subreaper, supervises at least one other process). And as long as your pid 1 executes into something that fulfills these duties, your system will work. Luckily enough, I have several ways to achieve what I want, but in my opinion, using init's arguments would have been the most elegant option. "init" was not made to take or use any arguments, and that dates back to decades ago. It's just the way it was designed. But nothing prevents you from writing a trivial shell wrapper that does take arguments and runs as your starter init. And that is, IMO, the most elegant solution (because it's the simplest). I'm really interested in knowing which is the real reason behind this feature and if there is any chance that a patch would be accepted, to either remove, or allow to disable this part of the code. The real reason is the one you read in the comment: any arguments would show up in the "ps" output after the "init" name, and that would be ugly and inconsistent with the behaviour of other "init" implementations. Since init is not supposed to take any arguments, this normally doesn't matter. If taking arguments matters for your use case, then "init" is not the program you want to run as your pid 1 - not in the first place anyway. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: why are init's arguments wiped ?
On 29/01/2016 17:50, Nicolas CARRIER wrote: I quite agree with dietmar, concerning uglyness... That doesn't change the fact that it's the behaviour of every init binary since 1970 and that you should come with a better reason if you want to change it, especially since it's so easy to accomplish what you want with a little workaround. And concerning the replacement of init with a script, well, hum... :D Is it even possible ? It is very possible, and a lot of init systems do this. If you are using a distribution that comes with an initramfs, you are using this feature every time you boot. Won't it suffer from the lack of proc / sys and dev ? Environment variables setup by init ? This does not matter if all you want is to get command-line arguments and store them somewhere (in the environment, for instance). What's more, there is a risk to spawn multiple processes (eval ?) before init is launched and the previous questions do apply. No risk. The only important thing is to make sure your pid 1 does not die, and eventually execs into init. Your zombies will all be reaped when init starts. In the meantime, I find it rather strange that busybox wipes it's arguments, knowing that passing arguments to init is a feature supported, at least, by linux and that only argv[1] is parsed, so extra arguments would do no harm. The ps argument is quite strange, why does it matter ? "Cluttered" command-lines are quite well accepted for other processes, why would init be any different ? Because it's a convention that init prints "init" and nothing else (or sometimes its default runlevel) in the process list. Also, the fact that nothing under init actually uses the arguments to init, so it should not matter at all. Using /proc/1/cmdline to get those arguments is very ad hoc ; this is not a POSIX way to transmit information to other programs, and init is free to not support it. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: anyone interested in bringing launchd to BusyBox?
The technical impact of Denys's change was actually extremely small, which is the main reason why it was not discussed (much) on the list. The change was meant to send a political message, and it has done so quite successfully. The message is: Busybox will not yield to aggressive expansionism. The message is not "Busybox needs a new init system" or "Busybox needs a service manager". So far Busybox has done a good job of focusing on mechanism and keeping away from policy decisions or endorsing a system more than another. (And even though I like the model and have personal interests in seeing it spread widely, I think adding tcpserver and runit as busybox applets was unwise, because contrary to that agnosticism.) I would like it to remain that way, *especially* when it's about such a politically heavy weighted subject as a service manager. Busybox is useful when it's about providing clean, small implementations of standard tools other implementations of would be too big to fit on embedded platforms. Good system software will naturally compile and fit into integration projects without needing to be rewritten and be provided as a part of Busybox. It is true for runit, it is true for the s6 family of tools, it may be true for relaunchd (if you remove the build-time Ruby dependency). Integrating that kind of software into busybox has no technical benefits, it only serves to advertise the project; and that is unfair both to competitors who refrained from attempting to get aboard the Busybox train, and to Busybox users who have no wish to see their tool of choice become a battleground for popularity contests and political agendas. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: confusing behavior with no inittab and non-tty stdin
On 05/11/2015 06:33, Tycho Andersen wrote: I'm experiencing some confusing behavior with busybox when running it in an LXC container. In particular, this means that stdin, stdout, and stderr are all /dev/null when busybox is exec()'d as init. The relevant function is console_init() in init/init.c in the busybox source. Try setting the CONSOLE environment variable to "/dev/console", or whatever device your console is (seen from inside the container), before executing busybox init. init will only reopen its standard descriptors when it doesn't find such a variable. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] inotifyd: -x: new option
On 20/10/2015 13:17, Denys Vlasenko wrote: inotifyd syntax is "inotifyd PROG FILE1[:MASK]...", and PROG is run with PROG ACTUAL_EVENTS FILEn [SUBFILE] This severely limits the number of unmodified PROGs you can run to achieve some useful result. (...) IOW: in practice, you always need a shim. Ah, indeed. It's a shame PROG is a single argument, though: I very much prefer executing whole command lines. If you have to tailor PROG to inotifyd's needs anyway, the "it's less code" argument falls. Sorry, but I don't agree to this view even after you repeat it. Here is an example where this idiom of "killing the parent" is used already: Well, giving me another example of this idiom doesn't convince me that it's a good one either. :P ntpd, just like inotifyd, can be killed by one of its children? I still don't like it. I'm a Unix traditionalist and reactionary: parents should have control over their children, not the other way round. Can you point me to the software you are working on so that I can look on a wider picture of the problem you are trying to solve? That would be Bartosz. I'm not working on any software using inotifyd, I was just adding my support to his proposal from a pure "Unix software design" point of view. But for me it's theoretical, and borderline bikeshedding, and I can work with your design even if it's not my preferred one - so if you won't be convinced, that's ok too, and I'll just drop it. :) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH v2] inotifyd: -x: new option
On 16/10/2015 20:29, Denys Vlasenko wrote: I think killing $PPID from children is a completely legitimate approach. FWIW, I dislike parricide. The flow of information is backwards; it forces the child to know in what context it is run. I agree with Bartosz in that it is much cleaner to encode information in the child's return code, and have the parent explicitly support a code that makes itexit. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support denying accounts with blank password
On 14/10/2015 08:37, Natanael Copa wrote: using a screen and keyboard or via serial cable. he logs in as root, but is not asked for password or just press when asked for password. What companies usually do in this case (typically ISPs with modems they ship to users) is set a trivial root password, such as "admin", and disable privilege-gaining binaries entirely, except /bin/login which checks /etc/securetty. It's not much harder for a non-technical user to log in with a trivial password than with no password at all, and it ensures that only local users can log in as root. (Of course, ISPs have their own backdoors into those modems, but that is another story.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: rm -f can fail
On 13/08/2015 12:36, Bastian Bittorf wrote: maybe this is a race? root@box:~ rm -fR /tmp/dbcache rm: can't remove '/tmp/dbcache': Directory not empty root@box:~ echo $? 1 Most likely a race. It's impossible to atomically remove a directory with Unix. (There's a way to emulate that: first rename() the directory to something unique and unpredictable, then rm -rf that directory. But AFAIK, no rm implementation proceeds like this, and there's still a small risk that it won't work.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC/PATCH 09/10] readahead: applet extension
On 13/08/2015 15:57, Bartosz Golaszewski wrote: Implement daemon mode for readahead. Please at least add a config guard so it can be deactivated at compile time (no matter what the default setting for the readahead applet selection is). This is feature creep and makes me quite uncomfortable. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC/PATCH 06/10] libbb: add fanotify support on uClibc
On 13/08/2015 15:57, Bartosz Golaszewski wrote: Fanotify syscalls are not supported in uClibc. Add a new include file - missing_syscalls.h - implementing the syscalls directly in busybox. It's not a good idea to start fixing libc problems in applications. If you want to use a system call that your favorite libc doesn't support, please go fix your favorite libc instead of making busybox uglier - why should busybox carry that responsibility? Also, it's a bug to guard features with a macro that only identifies an implementation. If one day the stars align and a new uClibc release comes out that implements fanotify(), your code will break, or become redundant at best. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Unable to disable CONFIG_FEATURE_SYSLOG
On 27/07/2015 17:03, walter harms wrote: Interestingly it seems a bit complicated to have a system without syslogd. Without syslog, i.e. the client part. A quick grep in the source shows that at first sight, FEATURE_SYSLOG is only used in two places, libbb/verror_msg.c and libbb/info_msg.c, to guard calls to syslog() and vsyslog(). Makes sense to me. If I haven't selected any app that can actually use syslog, it's sane to not pull in the syslog() implementation code. It's a cool optimization and there's not much room for simplification here. syslogd, the server part, is a whole other enchilada, but it can be disabled via a simple option in the Kconfig, so no problem there either. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/2] Revert ash: use alloca to get rid of setjmp
On 22/07/2015 13:46, Xabier Oneca -- xOneca wrote: I've read alloca is not portable anyways... It's probably portable on every platform busybox is running on. (I'm not advertising its use, just saying I don't think it's the right argument for not using it.) I'm not an expert, but why not just use plain ol' malloc? malloc uses the heap. It's more complicated, pulls in more code, takes more time to run, and requires manual management; whereas alloca and VLAs use the stack, which is smaller, simpler and faster. For a minimalistic piece of software such as busybox, it makes sense to avoid using the heap when it can be avoided. I don't use alloca, but I'm a big fan of VLAs; they save me lots of calls to malloc, and a good portion of the programs I write don't use the heap at all (which is a nice way to ensure they will never leak memory). However, like Denys, I thought that programs simply crashed when the kernel couldn't allocate them enough stack; on MMU systems, there's no reason why the kernel can't enforce a bound, or simply let the stack run unbounded. Rich (or anyone), any good pointers to read about this ? -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: osuosl.org and Spamhaus PBL
X-Greylist: delayed 00:06:59 by SQLgrey-1.7.6 (For the record, I read the headers wrong, and it's osuosl.org that actually performs that greylisting. My apologies to Numericable, for once I accused them wrongly. Now to understand what that greylisting does for osuosl.org... if they're using PBL in the first place, and only accept SMTP connections from known ISP servers... oh well, some things are best left unexplained.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
osuosl.org and Spamhaus PBL
Hello, The latest message I sent to the list was blocked by the busybox.net MX because my IP was listed in the SpamHaus PBL - that means it is a dynamic address provided by my ISP, which it indeed is. Mail servers that reject mail based on a PBL listing basically enforce the use of the provider's SMTP server and disallow use of the customer's own SMTP server. I have my own SMTP server. It works, it has always worked, and if it doesn't work, I can fix it. I do not want to use my ISP's SMTP server for several reasons: - If at some point I want to encrypt my mail, I want it to be done between my server and the recipient's server, not between my server and my ISP's. I don't want to allow my ISP to read my mail. - My ISP is made of incompetent morons who have no idea what customer service is, how the Internet works or how to configure or scale a service. Every mail I send through them sits in their queue for several minutes. The previous mail I sent had this charming header in it: X-Greylist: delayed 00:06:59 by SQLgrey-1.7.6 (so it wasn't actually incompetence in this case, it was intentional disservice.) The PBL is part of a larger tendency to disempower individual users and put that power into the ISP's hands, which comes with a very unsavory smell of surveillance, breach of net neutrality, and also user infantilization and deresponsabilization. It's the first time I get a bounce based on a PBL listing, and the busybox.net MX is the first MX giving me such a bounce. I have to say it is a major disappointment coming from such a list. I noticed in the headers that the osuosl.org servers were actually hosting the list. So it looks like osuosl.org implements PBL blacklisting. It's the first time I send a mail to the Busybox list and it is rejected by PBL, so either the list hosting was switched to osuosl.org very recently, or they added the feature recently. Would it be envisionable to either switch hostings again, or persuade osuosl.org to roll this back (one can hope) ? I want to think that busybox.net people are technically savvy, responsible people who dislike this kind of disempowerment as much as I do, and that my plea will fall on listening, understanding ears. Thanks. (osuosl.org homepage: The Open Source Lab is an organization working for the advancement of open source technologies. They forgot to mention without consideration as to how they are applied.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How is syslog output printed on TTY?
On 03/07/2015 13:53, john smith wrote: I wonder then where does this text come from? It may be specific to NOOBS but I am not sure. When syslogd is not running, syslog() will send its output to /dev/console, which is what you are observing. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support denying accounts with blank password
On 09/06/2015 16:57, Isaac Dunham wrote: Or is blanking the root password completely wrong? I wouldn't say it's wrong, but it can be easily avoided. You can always use a trivial password such as root or admin for an initial machine setup. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] su: support denying accounts with blank password
On 09/06/2015 21:44, Natanael Copa wrote: It is an interesting dilemma. What is worse, blank root password or weak/default root password (eg 'root' or similar)? I'll suggest that it doesn't matter in the slightest, because a machine should only be in either state when it's on a trusted network where new machines are installed (or, if possible, on no network at all) and should never find themselves in those states out there in a place where users can connect to them. IOW, if a computer gets hacked because its root password was blank or default, it's not a problem you can solve by choosing the other solution. :) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Letting mdev + devtmpfs play together?
On 19/04/2015 18:57, Denys Vlasenko wrote: # !: do not create device node Ah, I missed the major = -2 trick. Sorry for giving out wrong information... I should check for all the available documentation before diving into the source (and verifying that the documentation is correct) . -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Letting mdev + devtmpfs play together?
On 18/04/2015 17:05, Floris Bos wrote: I tried enabling waiting for sequence numbers by echoing a newline to /dev/mdev.seq, however I noticed there are situations where that does not work properly either. Yes, it's the classic sequentiality problem. The userspace cannot guarantee that mdev #526 will take the lock before #527. If you want guaranteed sequentiality, you need to run a netlink reader. There have been several discussions on this list in the last month about how to do that. Currently, you can grab Alpine Linux's nldev, or s6-linux-utils' s6-devd, and run nldev mdev or s6-devd mdev as a daemon, which will do what you want. More discussion is on the way about adding that functionality to busybox. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Letting mdev + devtmpfs play together?
On 18/04/2015 18:00, Floris Bos wrote:
Simply letting devtmpfs instead of mdev handle the removal of the actual device
node files wouldn't be an option?
I don't think I have a real need for sequentiality on any other operation.
I'm not sure whether devtmpfs handles device node removal itself.
I'd need to test that.
In any case, the answer to your original question is no, you cannot
configure mdev to run but not remove nodes. You can patch it, though:
the relevant part of the code, which you may want to comment, is the
following block:
if (operation == OP_remove major = -1) {
if (ENABLE_FEATURE_MDEV_RENAME alias) {
if (aliaslink == '') {
dbg1(unlink: %s, device_name);
unlink(device_name);
}
}
dbg1(unlink: %s, node_name);
unlink(node_name);
}
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] mdev: support reading events from stdin, add features to mdev -s
On 15/04/2015 18:46, Denys Vlasenko wrote: How about the following applet, which would listen to netlink and spawn a helper for every new message? There are arguments for it and against it. We addressed that in the giant thread that happened last month. Grep your mailbox for mdev -i. The short version is that the people who are interested in your ndev functionality already have it, at least twice. :P mdev -i solves a different issue. (Sorry Isaac, haven't gotten around to reviewing your code yet.) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] libb/remove_file.c: Use correct algorithm to delete directory
On 13/04/2015 12:54, Leonid Fedorenchik wrote:
opendir();
do {
unlinked_files = 0;
while (readdir()) {
unlink();
unlinked_files = 1;
}
if (unlinked_files)
rewinddir();
} while (unlinked_files);
closedir();
That is actually incorrect. It depends on non-portable and
unspecified directory implementation.
The readdir() specification page you linked says:
If a file is removed from or added to the directory after the most
recent call to opendir() or rewinddir(), whether a subsequent call to
readdir() returns an entry for that file is unspecified.
Which means that it is very possible for readdir() to keep returning
NULL after a rewinddir() even if files have been added to the directory
in the meantime. The fact that your readdir() implementation doesn't is
accidental.
If you really want to use that algorithm, you have to loop around
opendir() and closedir(): re-open the directory after every pass, until
it is empty. But this is dangerous: it opens a race condition where you
could delete a new directory created by another process after you
successfully deleted the old one.
In other words, there is no way to atomically delete a file hierarchy
in Unix, and every rm -rf implementation is a compromise.
A way that I have found safer than most is the following:
* atomically rename() the directory to a non-existing, unique, random,
hard to predict directory name.
* recursively delete the newly named directory with your favorite
deletion algorithm. No matter what method you choose, there is still
a race condition, but the chances it will be triggered are significantly
reduced.
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] libb/remove_file.c: Use correct algorithm to delete directory
On 13/04/2015 13:38, Laurent Bercot wrote: Which means that it is very possible for readdir() to keep returning NULL after a rewinddir() even if files have been added to the directory in the meantime. Sorry, I was wrong about that. rewinddir() actually sets the directory in the same state as opendir(), so re-opening the directory after every pass is unnecessary. The reason why the algorithm is still susceptible to a race condition is that a file can always been added between the most recent invocation of opendir()/rewinddir() and the next invocation of readdir(). In other words, a concurrent process that constantly creates files will compete with the process that unlinks them, and the results are unpredictable. Also, the concurrent process can still create a file between a readdir() that returns NULL (which will be interpreted as success, the directory is empty, we can now unlink it) and the unlink(): so unlinking the directory name can still fail. I apologize for the confusion: I gave the wrong reason why this algorithm is not better than the current busybox one. The fact remains that it is impossible to guarantee that the unlink() of a directory will succeed, and adding a rewinddir() loop does not add value. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
Well, I've poked at this a little this evening. See https://github.com/idunham/busybox (in branch mdev) if you're curious about details. Hi Isaac, Nice job! A few comments: - Original mdev relies on getenv/putenv to handle environment variables; that's okay, because it's a short-lived program. But mdev -i is a long-lived program, so using and modifying its own environment for every event is conceptually unsatisfying, and ends up in a lot of unnecessary malloc/free/reallocs. It would be faster and more memory-efficient to allow handle_event to work with the raw string containing the VAR=VALUE\0 pairs. I realize it may require modifying all the getenv() invocations in the rest of mdev, but I believe it's worth it. (Heavy getenv() usage in mdev was one of the parts that made me postpone my plans of modifying it myself...) - Why do you need to memset practically the whole buffer every poll() iteration ? You know where you read and how many bytes you read, it should be possible to be unaffected by irrelevant data in the part of the buffer you're not using. (It would also be nicer to have real circular buffer management, but that's a lot of code, with struct iovecs and such; not sure if it's worth, considering very few busybox applets would benefit from it.) Thanks for getting to the dirty work, I really appreciate it! -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
On 20/03/2015 17:47, Isaac Dunham wrote: I'm not sure I follow you on the malloc/free/realloc bit: -as far as I know, getenv() does not malloc() anything, but returns the numeric value of a pointer within char ** environ getenv() is not a problem indeed. (Reading is rarely a problem, it's writing that's tricky.) -according to the manpage, putenv() does not copy the string, but modifies environ by inserting a pointer to the string. If the environ buffer is too short, environ may be expanded by calling realloc() - is this what you refer to? Yes, partly. But you would *also* have to copy the string. You cannot have an environment variable pointing into a temporary buffer, that you may overwrite on subsequent reads. Sure, it's very unlikely to happen, given the kind of data coming out of the netlink, but you cannot guarantee it won't. Generally, you don't want to store pointers to short-lived storage. since I'm using pointers into msgbuf. I don't think you can do that safely. You can use pointers into msgbuf for the current event's lifetime, because nothing's going to overwrite msgbuf during that span; but the environment is more permanent. I'm thinking that it may make sense to use getkey(char *key, char *buf, size_t n); in places that use getenv(key); Yes, I think it's the right solution. Don't tie your key-value store interface to a given implementation. :) I should probably replace the memset() before read() with msgbuf[len] = 0; after read(). I was just using a hammer to deal with strlen possibly overrunning the buffer, should we ever read something that ends with a partial KEY=VAL pair and no NUL terminator. The function you're looking for is strnlen(). [ circular buffer code ] If that's desired, someone else will need to do it. I already have that code in skalibs. But as I said, I'm not going to skalibsify busybox - as much as I'd like it, it is too slippery a slope. I waited as long as I did in hope that someone else would pick it up. Same here. Thanks for being even less patient than I am. ;) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 18/03/2015 18:08, Didier Kryn wrote: No, you must write to the pipe to detect it is broken. And you won't try to write before you've got an event from the netlink. This event will be lost. I skim over that discussion (because I don't agree with the design) so I can't make any substantial comments, but here's a nitpick: if you use an asynchronous event loop, your selector triggers - POLLHUP for poll(), not sure if it's writability or exception for select()- as soon as a pipe is broken. Note that events can still be lost, because the pipe can be broken while you're reading a message from the netlink, before you come back to the selector; so the message you just read cannot be sent. But that is a risk you have to take everytime you perform buffered IO, there's no way around it. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
On 15/03/2015 14:29, Natanael Copa wrote: It should be possible to solve the hotplug problem by setting up netlink listener, wait for event, when event arrives fork helper and just hand over the netlink socket filedescriptor to the child. That way we avoid pipes/fifos alltogehter. And we avoid the splitted messages problem too. Nope, you can't solve the split messages this way, and even if you could, you would need to make the helpers netlink-aware. The netlink socket is a datagram socket, not a stream one, whereas an external helper will expect a stream on stdin. As long as it reads stdin with read() instead of recvmsg(), the problem remains the same. You can say that external helpers will have to expect datagrams on stdin, but in that case those helpers have to do all the netlink protocol parsing themselves; all you save is the initial connect(), and you simply invented netlink activation, if you catch my drift. To really gain something valuable and enable the use of helpers that have no idea what the netlink even is, it's necessary to convert the series of datagrams into a stream - so the anonymous pipe is the simplest solution. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
On 15/03/2015 15:52, Natanael Copa wrote: I have simplified the long-time living netlink listener more by forwarding the netlink socket and letting the handler read directly from netlink. This factorize out the pipe and remove the need of any micro protocol. As I wrote in another message, there is basically no benefit in doing that, because it forces the handler to be netlink-aware. It should also make it easier to use posix_spawn() instead of fork/exec. The only difference is a potentially empty posix_spawn_file_actions_t, which is a minor detail. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 15/03/2015 19:39, Harald Becker wrote: On most systems it is perfectly possible to have multiple readers on a pipe, when all readers and writers be so polite to use the same message size (= PIPE_BUF). On most (but not all Unix systems) the kernel guaranties not only atomicity for write operations, but also for read operations (not in POSIX, AFAIK). Second sentence of http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html : The behavior of multiple concurrent reads on the same pipe, FIFO, or terminal device is unspecified. What most systems do in practice is irrelevant. There is no guarantee at all on what a system will do when you have multiple readers on the same pipe; so it's a bad idea, and I don't see that there's any room for discussion here. If, say, Linux has documentation somewhere explaining what it does with multiple readers on a pipe, and committing to NOT changing that behaviour EVER, then it might be reasonable for Linux-specific software to rely on it. I'm not aware of such a piece of documentation though. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 15/03/2015 20:41, James Bowlin wrote: http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html : ^ For goodness sake. This appears to be an argument merely for the sake of having an argument. This is POSIX.1-2008, the very specification that Linux, and other operating systems, are supposed to implement. It is the authoritative reference to follow whenever you're designing Unix software. I don't understand what your objection is. A FIFO special file (a named pipe) is similar to a pipe, except that it is accessed as part of the filesystem. It can be opened by multiple processes for reading or writing. Yes, I know the Linux man pages, and of course multiple processes are allowed to open a pipe for reading. But there is nothing in that page that documents what Linux does when multiple processes actually attempt to read on the same pipe. [] and committing to NOT changing that behaviour EVER, IMO this is a ridiculous demand that can't ever be met by any software. This is called specification and normalization, i.e. what standards are for. Sure, standards change and evolve, and that's a good thing; my point is when something is explicitly non-standardized, it is not a good idea to do that thing and expect a fixed behaviour. There really is no room for disagreement here. For my users the current busybox mdev hotplugging is not 100% reliable (more like 99+% reliable) which is a big pain. I'd love to see other busybox hotplug solutions that are selectable at runtime. So would I, and the solution you're looking for is called netlink + mdev -i, which is all that remains to be implemented. I would really like to cut on the bikeshedding and see some real work done now; if nothing has appeared when I get some time, I'll do it myself - which so far seems the only way to get things done, and which will help you much more than buggy solutions in search of a problem. It is very kind to try to help someone else from wasting time on a technically inferior solution but at some point it is better for everyone to just let them go ahead and use their time as they see fit. Multiple readers on a pipe is not technically inferior, it is technically *invalid*. I'm not preventing anyone from coding anything, but I will fight inclusion of buggy code into busybox, which is a major disservice to do to you and your users. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 15/03/2015 23:44, Harald Becker wrote: There are to many stupid programmers out there, who would try to add something like that into system management related programs. Couldn't go worser. Even if it works, at the first glance, it is error prone, and the next who change message size of one process, will break the chain, and possibly smash the system (as running with root privileges). Laurent just overlooked my lead in just for curiosity. And (again) that's it: curiosity. ... at least until reactions have bean standardized, clearly documented (not same as former), and guarantied. Yes. Thank you for acknowledging it and for alleviating my fear. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 15/03/2015 21:54, Harald Becker wrote: My lead in was: just for curiosity, and that's it, it works on many systems. ... but I never proposed, doing something like that. It's what my lead in says: curiosity. Okay, fair enough. Please let's not do it then. :) -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC] Proof-of-concept for netlink listener for mdev -i
On 14/03/2015 20:23, Rich Felker wrote:
Could you elaborate on how you measure that? With musl only the parts
of stdio you actually use will be linked, and use of exit does not
result in linking of any additional code, since the startup code has
to call exit(main(...)) anyway. In any case exit and its dependencies
are tiny.
The die(), edie() and dbg() functions/macros in the example use printf
format strings and variable arguments, I assumed they are built around
a function of the printf family.
gcc 4.8.1, musl from 2014-12-23, Linux 3.10, x86_64.
$ cat nostdio.c
#include unistd.h
int main (void)
{
write(1, Hello World!\n, 13) ;
return 0 ;
}
$ gcc -O2 -static -o nostdio nostdio.c strip nostdio
$ wc -c nostdio
2952 nostdio
$ cat stdio.c
#include stdio.h
int main (void)
{
printf(%s!\n, Hello World) ; /* avoids gcc magic */
return 0 ;
}
$ gcc -O2 -static -o stdio stdio.c strip stdio
$ wc -c stdio
15224 stdio
That's almost 3 pages.
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
On 13/03/2015 21:32, Michael Conrad wrote: I stand corrected. I thought there would be a partial write if the pipe was mostly full, but indeed, it blocks. Except you have to make the writes blocking, which severely limits what the writers can do - no asynchronous event loop. For a simple cat-equivalent between the netlink and a fifo, it's enough, but it's about all it's good for. And such a cat-equivalent is still useless. It's still a very bad idea to allow writes from different sources into a single fifo when there's only one authoritative source of data, in this case the netlink. If a process wants to read uevents from a pipe, it can simply read from an anonymous pipe, being spawned by the netlink listener. That's what my s6-uevent-listener and Natanael's nldev do, and I agree with you: there's simply no need to introduce fifos into the picture. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
