Question about nslookup
Hello. I am working in the field of Particle Physics and setting up the init sequence of a group of diskless single board computers (Emerson Network Power MVME3100). I have made an initramfs with a statically linked busybox and a collection of scripts. I want to automate the init process so that it can run in various places where both the host and the NFS server can take various addresses. For the address of the NFS server, I just put a list in a file in the initramfs. For the host address I perform a DHCP request and it works well. There is another thing I would like to do: get the hostname from the network. Once udhcpc has configured eth0, I know the IP address. Then I issue an nslookup with this address and I expect to find the hostname in the response. But it does not work and I have to look into my own hand-written /etc/hosts to get it. The final OS is Debian Lenny. I recently compiled busybox-1.15.2 to give a try the nslookup applet in the running Debian environment. There it works. But not in a chroot containing the same files as my initramfs. Here is the response in the Debian system: k...@apcdc4:~$ /busybox-1.15.2/bin/busybox nslookup apcdc4 Server:134.158.184.54 Address 1: 134.158.184.54 apcdns01.in2p3.fr Name: apcdc4 Address 1: 134.158.186.184 apcdc4.in2p3.fr k...@apcdc4: And in my chroot /busybox-1.15.2: # nslookup apcdc4 Server:134.158.184.54 Address 1: 134.158.184.54 nslookup: can't resolve 'apcdc4' I have copied the following files in the /etc of the chroot: host host.conf nsswitch.conf services The executable is exactly the same in both cases and it is statically linked. There must be some file missing but which one? Thanks for your help. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question about nslookup
Denys Vlasenko a écrit : On Fri, Mar 19, 2010 at 2:40 PM, Didier Kryn k...@in2p3.fr wrote: I am working in the field of Particle Physics and setting up the init sequence of a group of diskless single board computers (Emerson Network Power MVME3100). I have made an initramfs with a statically linked busybox and a collection of scripts. I want to automate the init process so that it can run in various places where both the host and the NFS server can take various addresses. Forthe address of the NFS server, I just put a list in a file in the initramfs. For the host address I perform a DHCP request and it works well. There is another thing I would like to do: get the hostname from the network. More natural method would be to get hostname via DHCP. Try to configure your DHCP server to provide hostnames too in its responses. Maybe there is a new feature but this is the fist time I read that DHCP server provide address names. And it does not seem that udhcpc gets it. Another method is to agree on some fixed formula how to assign hostnames depending on the IP. Every network administrator in every institution has his own private scheme. Final method is to not bother knowing your own hostname. It is not really needed unless you are a server. (And if you are, you don't use DHCP dynamic IP). I usually set it to localhost. Technically it's true, even if I boot with no network at all: my address is 127.0.0.1, it maps to localhost, so obviously I am localhost. :D I am an ssh server. And, when typing ssh somehost.somewhere, I like to read somehost in the prompt. Because there are so many reasons of mistakes. Imagine you have 2 identical boards in one place and the all prompt like localhost. Once udhcpc has configured eth0, I know the IP address. Then I issue an nslookup with this address and I expect to find the hostname in the response. But it does not work and I have to look into my own hand-written /etc/hosts to get it. The final OS is Debian Lenny. I recently compiled busybox-1.15.2 to give a try the nslookup appletin the running Debian environment. There it works. But not in a chroot containing the same files as my initramfs. Here is the response in the Debian system: k...@apcdc4:~$ /busybox-1.15.2/bin/busybox nslookup apcdc4 Server:134.158.184.54 Address 1: 134.158.184.54 apcdns01.in2p3.fr Name: apcdc4 Address 1: 134.158.186.184 apcdc4.in2p3.fr k...@apcdc4: And in my chroot /busybox-1.15.2: # nslookup apcdc4 Server:134.158.184.54 Address 1: 134.158.184.54 nslookup: can't resolve 'apcdc4' I have copied the following files in the /etc of the chroot: host host.conf nsswitch.conf services The executable is exactly the same in both cases and it is statically linked. There must be some file missing but which one? It is likely /etc/resolv.conf In principle, there is always a DNS available through a broadcast request. I have copied the /etc/resolv.conf from my normal Debian to the chroot and it does not help. strace your nslookup run to find it out for sure. Yep, I'll try to sort out the strace log. Thanks. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] nologin: new applet.
Guys, I apologize for contributing to the noise on this thread, just for a comment: To deny access to users, there are several means, including /bin/false or an exclamation point in /etc/passwd. /bin/nologin is meant to deny access in a *gentle* way, for example to inform known persons that their account has been disabled. This implies that they must be able to read the message. Didier Le 07/11/2011 04:21, Harald Becker a écrit : Hallo Natanael! Consider doing a sleep (2 or 3 seconds) after message output before dieing. If nologin is run via a standard init/getty/login sequence, the screen is most likely cleared shortly after exit of nologin hence humans do not have a chance to read the message without a delay. In addition the delay allows to slow down login attacks (paranoia). I think this tool is intended for passwordless accounts (daemons etc) and this case a delay is meaningless. True that nologin is for daemon accounts etc. ... but in cases where a typo leads to one of those accounts any message vanishes before a human can read it. IMHO is displaying a message without a final delay nothing more than calling /bin/false with a different name. I hate such programs don't considering the context they are used. And nologin is used in a context where the screen is probably cleared only milliseconds after nologin exits (init/getty/login). So that single sleep allow humans to read the message emitted by nologin, what else is the reason to emit such a message if there is no chance to read? Is there any situation where that delay before exit produces any kind of trouble? -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Problem with sysinit actions from inittab
Hi Alexander. If your console is supposed to be a serial port, then you have a problem with inittab. Your inittab, seems to be meant for virtual terminal, with tty1 as the console, and ctlr-alt-del setting. If you use a serial port, you must uncomment the line with ttyS0 in the inittab and comment anything related to virtual terminal (tty1..tty8). Hope this helps.Didier Le 18/11/2011 09:16, Alexander Varnin a écrit : Hello. I'm building OS using buildroot, and i get problem with busybox init - programs from inittab, marked with sysinit action doesn't execute. Shell, that is marked with respawn action starts ok. I've checked it with a series of commands. I'm attaching log of this commands. Please, take a look and tell what can be the problem? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox re ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Mounting Filesystem over existing directory
Hi Sameer. There is a very simple alternative in case you only need to update a small number of well known files: softlink them to some r/w location, like /var/run or /lib/init/rw, which you mount on tmpfs. The second of these locations is created early in newer Debian versions and used by some packages like resolvconf. Didier Le 31/05/2012 08:04, Bartos-Elekes Zsolt a écrit : Michael Conrad wrote: Unionfs has one problem though: the only way to get correct behavior is to merge path A and B onto mountpoint C. (C can't be the same as A or B). Perhaps this is valid only for older versions of unionfs. I am using unionfs mounted on /var that is composed of a tmpfs mounted on /mnt/tmpfs, and the original /var that is on the flash (containing only a few important files and directories that must be preserved across reboots, like /var/lib/dpkg). $ mount | grep unionfs unionfs on /var type unionfs (rw,relatime,dirs=/mnt/tmpfs=rw:/var=rw) ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: How to add an existing user to an existing group
Hi Jan. I think it is just the oposite of what you typed: adduser daemon mygroup At least for GNU's adduser. Maybe BB's adduser misses the feature, otherwise the error message would be weird. Didier Le 18/09/2012 09:24, Jan Pohanka a écrit : Hello, I can't found proper command to add an existing user to an existing group. I have tried following: user daemon exists as well as group mygroup # adduser -D -H -G mygroup daemon adduser: user 'daemon' in use Tested on Busybox v1.20.0 regards Jan ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Why '-c DEV' option for switch_root?
Hi Laurent. I am using initramfs with static Busybox on VME Single Board Computers. These are used as servers and can be plugged into various locations where there is a dedicated NFS server. A USB or sata disk can also be connected. The kernel boots from onboard flash and the console is a serial port. The user-space code in the initramfs configures the network, requests its own hostname from DNS, detects available bootable filesystems (disk or NFS), figures out from a list at which address there might be an NFS server, then presents a list of systems to boot to -- after 15 seconds, selects the first in the list -- Then mounts proc, sys and dev in the mounted filesystem, and switch_root to /sbin/init. The mounted filesystem is currently Debian-7. I apreciate your knowledge of Linux and the boot process. But about the usefullness of initramfs, I think you are wrong. I don't think I could do the job without it. Didier Le 16/12/2013 09:05, Laurent Bercot a écrit : On 2013-12-16 01:08, Rob Landley wrote: The most recent kernel has my initmpfs patches, meaning initramfs can now be a tmpfs instead of ramfs. [snip blurb] You're listing reasons why initramfs (or initmpfs, if you prefer) is more logical than it was before, more convenient, etc. All this may be true, but it does not mean initramfs is actually *useful*. I have yet to see a case where initramfs is really needed. Every time I've seen a system boot on initramfs, the same goals could have been achieved via booting on the real root filesystem and doing work during initialization, which implies a lot less code, and is more maintainable, and safer (if something fails early on). I liked initramfs back in the day. It looked flexible and powerful, which it is, and maybe your initmpfs patches make it even more so. But I've come to realize it's just a fancy toy, and yes, a trap : people are blinded by the shinies and diverted from simpler solutions. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Why '-c DEV' option for switch_root?
Hi Laurent. I actually have a jffs2 filesystem on another part of the flash memory, but I decided not to use it for the purpose, for one reason: A single stupid bug might make the device non-bootable. Because, even if the jffs2 or squashfs is initially mounted read-only, the main reason to use it is the possibility to remount it read-write and modify it. You see the point? Better work hard in the beginning to work out a good stable initramfs which nobody can change/corrupt. With the initramfs, you restart always from a clean situation (once debugged of course). And the userland in my initramfs has a possibility to escape the normal sequence and start an interactive session, which allows to debug the environment. By the way, you wrote that initramfs is a trap. What is the trap, is it initramfs or the need for swhtch_root? Is it different if I switch_root from another filesystem? Didier Le 16/12/2013 19:45, Laurent Bercot a écrit : But about the usefullness of initramfs, I think you are wrong. I don't think I could do the job without it. Hi Didier, Eh, you could. You have some flash to boot the kernel from: you could as well have a small squashfs root filesystem on it with a script that performs all the initialization work you're currently performing in the initramfs. Whether or not that's better or not than initramfs is debatable. I find it better - and I think that you'll find it simpler to maintain if you try it out - but I realize that my views about this are not shared by many. The best approach, as always, is whatever works for you, your team, and your users. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Launching Linux from Busybox (pivot_root or switch_root, or ? )
Hi Stéphane. I do exactly what you want to do (I boot Debian Wheezy on diskless PowerPC servers): Here is my busybox init script (in initramfs) /bin/busybox mount -t proc none /proc /bin/busybox mount -t sysfs none /sys busybox --install export PATH=/bin:/sbin:/usr/bin:/usr/sbin # now configure network (I skip the dirty details) mkdir -m 755 /dev/pts mount -t devpts devpts /dev/pts mdev -s # now play private tricks to find usable root filesystems and decide which one to boot # more tricks to mount some tmpfs dirs like Debian's init expects them exec /sbin/switch_root $ROOTFS $INIT 2 The only difference I see with what you do is mounting /proc and running mdev. I guess you have the busybox links ready made since you don't run busybox --install. Of course, the init command you pass to switch_root must be executable. Critical point: your script or interactive shell must be process #1. One detail more: my busybox is statically linked; I don't know if it matters; just avoids the burden of shared libs. Hope it helps. Didier Le 10/06/2014 11:05, Stéphane Massot a écrit : Hi, On a beaglebone hardware, I want to start on a partition with a minimalist busybox system (/dev/mmcblk0p2), run some checks on the 2 other partitions (/dev/mmcblk0p5 /dev/mmcblk0p6) containing more complete Linux systems (Angström), then start on one or the other of the 2 Linux systems based on those tests. The problem is that I cannot find how to start another system correctly from busybox. What I did: From the (perfectly working) busybox system: /export PATH=/bin:/sbin:/usr/bin:/usr/sbin mount -t sysfs sysfs /sys mkdir -p /dev/pts mount -t devpts devpts /dev/pts mount /dev/mmcblk0p5 /mnt/root/ Then I tried 2 ways: *1) pivot_root* /cd /mnt/root pivot_root . ./initrd ./bin/mount -n --move ./initrd/sys ./sys ./bin/mount -n --move ./initrd/proc ./proc ./bin/mount -t devtmpfs none ./dev ./bin/mount -n --move ./initrd/dev/pts ./dev/pts exec ./usr/sbin/chroot . ./sbin/init ./dev/ttyO0 ./dev/ttyO0 21/ This gives the following error : /Couldn't find an alternative telinit implementation to spawn./ It then starts a new Angström login prompt, but after logging in, any call to init will return the error above, and the system doesn't work (for example, if I call reboot, it fails; if I call killall busybox, it triggers a reboot). I tried without the ./usr/sbin/chroot . , and it gives the same results. *2) switch_root* /exec switch_root -c /dev/ttyO0 /mnt/root /sbin/init/ This gives me a new busybox login prompt, and I am still on the busybox partition Any idea what I've done wrong ? Have I missed a step ? Any parameter I forgot to take into account or any method to see more details about what went wrong ? -- Stéphane Massot Lead Embedded Developper Téléphone : +33 (0)1 84 17 31 20 Portable : +33 (0)6 79 38 18 87 stephane.mas...@smart-impulse.com mailto:stephane.mas...@smart-impulse.com SMART IMPULSE 48 rue René Clair 75018 PARIS www.smart-impulse.com http://www.smart-impulse.com ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
Le 17/03/2015 19:56, Harald Becker a écrit : Hi Didier, On 17.03.2015 19:00, Didier Kryn wrote: The common practice of daemons to put themselves in background and orphan themself is starting to become disaproved by many designers. I tend to share this opinion. If such a behaviour is desired, it may well be done in the script (nohup), and the go to background feature be completely removed from the daemon proper. The idea behind this change is to allow for supervisor not being process #1. Ack, for the case the daemon does not allow to be used with an external supervisor. Invoking a daemon from scripts is no problem, but did you ever come in a situation, where you needed to maintain a system by hand? Therefor I personally vote for having a simple command doing auto background of the daemon, allowing to run from a supervisor, by a simple extra parameter (e.g. -n). Which is usually no problem, as the supervisor need any kind of configuration, where you should be able to add the arguments, the daemon gets started with. So you have to enter that parameter just once for your usage from supervisor, but save extra parameters for manual invocation. Long lived daemons should have both startup methods, selectable by a parameter, so you make nobodies work more difficult than required. Dropping the auto background feature, would mean, saving a single function call to fork and may be an exit. This will result in a savage of roughly around 10 to 40 Byte of the binary (typical x86 32 bit). To much cost to allow both usages? OK, I think you are right, because it is a little more than a fork: you want to detach from the controlling terminal and start a new session. I agree that it is a pain to do it by hand and it is OK if there is a command-line switch to avoid all of it. But there must be this switch. Could you clarify, please: do you mean implementing in netlink the logic to restart fifosvd? Previously you described it as just a data funnel. No, restart is not required, as netlink dies, when fifosvd dies (or later on when the handler dies), the supervisor watching netlink may then fire up a new netlink reader (possibly after failure management), where this startup is always done through a central startup command (e.g. xdev). The supervisor, never starts up the netlink reader directly, but watches the process it starts up for xdev. xdev does it's initial action (startup code) then chains (exec) to the netlink reader. This may look ugly and unnecessary complicated at the first glance, but is a known practical trick to drop some memory resources not needed by the long lived daemon, but required by the start up code. For the supervisor instance this looks like a single process, it has started and it may watch until it exits. So from that view it looks, as if netlink has created the pipe and started the fifosvd, but in fact this is done by the startup code (difference between flow of operation and technical placing the code). I didn't notice this trick in your description. It is making more and more sense :-). Now look, since nldev (lest's call it by its name) is execed by xdev, it remains the parent of fifosvd, and therefore it shall receive the SIGCLD if fifosvd dies. This is the best way for nldev to watch fifosvd. Otherwise it should wait until it receives an event from the netlink and tries to write it to the pipe, hence loosing the event and the possible burst following it. nldev must die on SIGCLD (after piping available events, though); this is the only supervision logic it must implement, but I think it is critical. And it is the same if nldev is launched with a long-lived mdev-i without a fifosvd. Well, this is what I thought, but the manual says an empty end causes end-of file, not mentionning the pipe being empty. end-of-file always include the pipe being empty. Consider a pipe which has still some data in it, when the writer closes the write-end. If the reader would receive eof before all data has bean consumed, it would lose some data. That would be absolutely unreliable. Therefore, the eof is only forwarded to the read end, when the pipe is empty. I agree that the other way wouldn't work. Just noticing the manual is wrong/unclear on that point. *Does anybody know the exact specification of poll behavior on this case?* My experience, with select() which is roughly the same, is that it does not detect EOF. And, since fifosvd must not read the pipe, how does it detect that it is broken? Not detect? Sure you closed all open file descriptors for the write end (a common cave-eat)? I have never bean hit by such a case, except anyone forgot to close all file descriptors of the write end. You notice that something happened on input (AFAIR) but I'm sure you don't know what. It may be data as well. You must read() to know. Anyway you don't want to poll() the pipe unless mdev-i is dead
Re: RFD: Rework/extending functionality of mdev
Le 16/03/2015 19:18, Harald Becker a écrit : On 16.03.2015 10:15, Didier Kryn wrote: 4) netlink reader the Unix way Why let our netlink reader bother about where he sends the event messages. Just let him do his netlink receiption job and forward the messages to stdout. netlink reader: set stdout to non blocking I/O establish netlink socket wait for event messages gather event information write message to stdout hotplug startup code: create a private pipe spawn netlink reader, redirect stdout to write end of pipe spawn fifosvd - xdev parser, redirect stdin from read end of pipe close both pipe ends (write end open in netlink, read in fifosvd) 1) why not let fifosvd act as the startup code? It is anyway the supervisor of processes at both ends of the pipe and in charge of re-spawning them in case they die. Netlink receiver should be restarted immediately to not miss events, while event handler should be restarted on event (see comment below). This would make the fifosvd specific to the netlink / hotplug function. My intention is, to get a general usable tool. I had not caught the point that you wanted it a general purpose tool - sorry. You won't gain something otherwise, as the startup of the daemon has to be done nevertheless. It does not matter if you start fifosvd, and then it forks again bringing it into background, and then fork again to start the netlink part, or do it slight different, start an inital code snipped, that do the pipe creation and the forks (starting the daemons in background), then step away. This is same operation only moved a bit around, but may be not blocking other usages. Sure it is the same. My point was about supervision. The netlink reader is a long lived daemon. It shall not exit, and handle failures internally where possible, but if it fails, pure restarting without intervening other action to control / correct the failure reason, doesn't look as a good choice. So it needs any higher instance to handle this, normally init or a different system supervisor program (e.g. inittab respawn action). OK, then this higher instance cannot be an ordinary supervisor, because it must watch two intimely related processes and re-spawn both if one of them dies. Hence, it is yet another application. This is why I thought fifosvd was a good candidate to do that. Also because it already contains some supervision logic to manage the operation handler. So, if fifosvd is a general usable tool, it must come with a companion general usable tool, let's call it fifosvdsvd, designed to monitor pairs of pipe-connected daemons. Where as the device operation handler (including conf parser) is started on demand, when incoming events require this. The job of the fifosvd is this on demand pipe handling, including failure management. 2) fifosvd would never close any end of the pipe because it could need them to re-spawn any of the other processes. Like this, no need for a named pipe as long as fifosvd lives. Dit you look at my pseudo code? It does *not* use a named pipe (fifo) for netlink operation, but a normal private pipe (so pipesvd may fit better it's purpose). Where as hotplug helper mechanism won't work this way, and require a named pipe (different setup, by just doing slight different startup). Yes, but it cannot work if the two long-lived daemons are supervised by an ordinary supervisor. Because one end of the pipe is lost if one of the processes die, and this kind of supervisor will restart only the one which died. And I have a suggestion for simplicity: Let be the timeout/no-timeout feature be a parameter only for the event handler; it does not need to change the behaviour of fifosvd. I think it is fine to restart event handler on-event even when it dies unexpectedly. ??? At some point you considered that the operation handler might be either long-lived or dieing on timeout. I suggest that the supervision logic is identical in the two cases. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
Le 18/03/2015 18:41, Laurent Bercot a écrit : 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. Hi Laurent. My experience is select() doesn't ever give you anything from exception, on Linux. And fifosvd must close the write end of the pipe; therefore cannot poll for writeability. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
Le 18/03/2015 20:01, Harald Becker a écrit : Do you think it matters losing one more event? Here we are considering the case when fifosvd is killed (say by admin's error). I understand lost events can be recovered. However there is one distinctive advantage in detecting immediately the death of fifosvd: nldev can die immediately, causing a new working chain to be estabished immediately, *before* a possible burst of events. This avoids forking 3 daemons just when the next event happens. The necessary code in nldev consists only in invoking sigaction() with a trivial intercept function and testing some flag on return from any blocked state (poll/read/write). Note that you probably already want this sigaction and intercept to capture SIGTERM. This is fine as long as the netlink reader keeps control on its exit, not if it's killed. And when netlink is killed, the it is the responsibility of the higher instance to bring required stuff up again. Sure, we agreed on that. But living orphans should not be left behind, and, in this respect, it is nldev which is in charge of fifosvd; the higher instance can't do it. This netlink reader you describe is not the general tool we were considering up to now, the simple data funnel. My pseudo code described the principal operation and data flow, not every glory detail of failure management. So the here described netlink is what I last called t(netlink the Unix way). If the idea is to integrate such peculiarities as execing a script, then it is not the general tool and why not integrate as well the supervision of mdev-i instead of needing fifosvd. The reason for fifosvd was AFAIU to associate general tools, nldev and mdev-i. ??? Don't know if I fully understand you here. And why shall exec a failure script violate making netlink a general tool? consider: nldev -e /path/to/failure/script I must say two things: First I didn't understand correctly what you had written and didn't apreciate the -e option. Second, I don't know what you include in the failure management, but I think part of it should be to get rid of the child. Doing it is going to be complicated in the script; at least you need to pass the pid because it is unknown to the shell. Instead, it is pretty simple in nldev: you just need to invoke wait() and syslog the exit status. The purpose of wait() isn't to check the pid of the process - we know who it is -, it's to remove the zombie, and get its exit status. This logic is no harm, whatever the way nldev is invoked. Even if it hasn't inherited a child, wait() returns immediately. I agree, though, that a comprenensive parsing of the status would take some lines of code. With may be a default of /sbin/nldev-fail. Maybe with a default behaviour of not execing anything - this option must be provided in some way. I skip the rest of the discussion because I would repeat the same things :-) And we agree that fifosvd can know the pipe is broken from the return code of the handler, and it's enough to have one way to know it. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
Le 18/03/2015 13:34, Harald Becker a écrit : On 18.03.2015 10:42, Didier Kryn wrote: Long lived daemons should have both startup methods, selectable by a parameter, so you make nobodies work more difficult than required. OK, I think you are right, because it is a little more than a fork: you want to detach from the controlling terminal and start a new session. I agree that it is a pain to do it by hand and it is OK if there is a command-line switch to avoid all of it. But there must be this switch. Ack! No, restart is not required, as netlink dies, when fifosvd dies (or later on when the handler dies), the supervisor watching netlink may then fire up a new netlink reader (possibly after failure management), where this startup is always done through a central startup command (e.g. xdev). The supervisor, never starts up the netlink reader directly, but watches the process it starts up for xdev. xdev does it's initial action (startup code) then chains (exec) to the netlink reader. This may look ugly and unnecessary complicated at the first glance, but is a known practical trick to drop some memory resources not needed by the long lived daemon, but required by the start up code. For the supervisor instance this looks like a single process, it has started and it may watch until it exits. So from that view it looks, as if netlink has created the pipe and started the fifosvd, but in fact this is done by the startup code (difference between flow of operation and technical placing the code). I didn't notice this trick in your description. It is making more and more sense :-). I left it out, to make it not unnecessary complicated, and I wanted to focus on the netlink / pipe operation. Now look, since nldev (lest's call it by its name) is execed by xdev, it remains the parent of fifosvd, and therefore it shall receive the SIGCLD if fifosvd dies. This is the best way for nldev to watch fifosvd. Otherwise it should wait until it receives an event from the netlink and tries to write it to the pipe, hence loosing the event and the possible burst following it. nldev must die on SIGCLD (after piping available events, though); this is the only supervision logic it must implement, but I think it is critical. And it is the same if nldev is launched with a long-lived mdev-i without a fifosvd. netlink reader (nldev) does not need to explicitly watch the fifosvd by SIGCHLD. Either that piece of code does it's job, or it fails and dies. When fifosvd dies, the read end of the pipe is closed (by kernel), except there is still a handler process (which shall process remaining events from the pipe). As soon as there is neither a fifosvd, nor a handler process, the pipe is shut down by the kernel, and nldev get error when writing to the pipe, so it knows the other end died. 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. You won't gain much benefit from watching SIGCHLD and reading the process status. It either will give you the information, fifosvd process is still running, or it died (failed). The same information you get from the write to the pipe, when the read end died, you get EPIPE. You get the information immediately from SIGCLD. You get it too late from the pipe, and you loose at least one event for sure, a whole burst if there is. Limiting the time, nldev tries to write to the pipe, would although allow to detect stuck operation of fifosvd / handler (won't be given by SIGCHLD watching) ... but (in parallel I discussed that with Laurent), the question is, how to react, when write to the pipe stuck (but no failure)? We can't do much here, and are in trouble either, but Laurent gave the argument: The netlink socket also contain a buffer, which may hold additional events, so we do not loss them, in case processing continues normally. When the kernel buffer fills up to it's limit, let the kernel react to the problem. Sure, the limit here is pipe size (adjustable) + netlink buffer size. ... otherwise you are right, nldev's job is to detect failure of the rest of the chain (that is supervise those), and has to react on this. The details of taken actions in this case, need and can be discussed (and may be later adapted), without much impact on other operation. This clearly means, I'm open for suggestions, which kind of failure handling shall be done. Every action taken, to improve reaction, which is of benefit for the major purpose of the netlink reader, without blowing this up needlessly, is of interest (hold in mind: long lived daemon, trying to keep it simple and small). My suggestion is: Let the netlink reader detect relevant errors, and exec (not spawn) a script of given name, when there are failures. This is small, and gives the invoked script full control on the failure management (no fixed functionality in a binary). When
Re: RFD: Rework/extending functionality of mdev
Le 16/03/2015 00:58, Harald Becker a écrit : We were looking at alternative solutions, so even one more: 3) netlink reader the Unix way Why let our netlink reader bother about where he sends the event messages. Just let him do his netlink receiption job and forward the messages to stdout. netlink reader: set stdout to non blocking I/O establish netlink socket wait for event messages gather event information write message to stdout hotplug startup code: create a private pipe spawn netlink reader, redirect stdout to write end of pipe spawn fifosvd - xdev parser, redirect stdin from read end of pipe close both pipe ends (write end open in netlink, read in fifosvd) The general scheme makes sense to me, but I would chane two details: 1) why not let fifosvd act as the startup code? It is anyway the supervisor of processes at both ends of the pipe and in charge of re-spawning them in case they die. Netlink receiver should be restarted immediately to not miss events, while event handler should be restarted on event (see comment below). 2) fifosvd would never close any end of the pipe because it could need them to re-spawn any of the other processes. Like this, no need for a named pipe as long as fifosvd lives. And I have a suggestion for simplicity: Let be the timeout/no-timeout feature be a parameter only for the event handler; it does not need to change the behaviour of fifosvd. I think it is fine to restart event handler on-event even when it dies unexpectedly. Didier This way we can let the starting process decide which type of pipe we use: private pipe for netlink, and named pipe for hotplug helper. I think this is not far away from Laurent's (or Natanael's) solution, at the only cost of a small long lived helper process, managing the on demand handler startup and checking for failures. Small general purpose daemon in the sense of supervisor daemons (e.g. tcpsvd), with generally reusable function for other purposes. ... better? Ok, but brings me to the message format in the pipe, I highly think, we should use a textual format, but do required checks for control chars and do some (shell compatible) quoting. This would allow to do: netlink reader /dev/ttyX (to display all device plug events on a console) netlink reader /tmp/uevent.log (append all event message to log file) ... and all such things. I know, the parser needs to do some checking and unquoting, but we have a single reader and it doesn't matter how much data it reads from the pipe in a single hunck, as long as the writers assure, they are going to write a single message with one write (atomicity). The parser assumes reading text from stdin, with required checking and unquoting. This way we get maximum compatibility and may easily replace every part with some kind of script. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: RFD: Rework/extending functionality of mdev
There are interesting technical points in this discussion, but it turns out to be mostly about philosophy and frustration. Harald, there are two points in your arguments which make no sense to me: Le 12/03/2015 17:31, Harald Becker a écrit : ... because there are people, wo dislike using netlink and want use the kernel hotplug helper mechanism. That's it. Peoples preferences are different. Opt out the functions you dislike in BB config. Hotplug is KISS, it is stupid, maybe, but it is so simple that you can probably do the job with a script. The same serialization you propose to implement in user space by the mean of several processes, a named pipe and still the fork bomb, has been implemented in the kernel without the fork bomb: it is called netlink. These people you are talking of, who would like to see hotplug serialized but do not want netlink, do they really exist? This set of people is most likely the empty set. In case these really exist, then they must be idiots, and then, well, should Busybox support idiocy? Le 11/03/2015 19:02, Harald Becker a écrit : It is neither a knowledge nor any technical problem, it is preference: I want to have *one* statical binary in the minimal system, and being able to run a full system setup with this (system) binary (or call it tool set). I agree it's fun to have all tools in one static binary. But I dont see any serious reason to make it an absolute condition. You speak of *preference*, but this very one looks pretty futile. I don't see the problem with having even a dozen applications, all static, why not, I'm also a fan of static linking. Best regards. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: why are init's arguments wiped ?
Le 29/01/2016 17:32, Isaac Dunham a écrit : for opt in $#; do case "$opt" in (*=*) eval "$opt" ;; esac done exec busybox init $@ Isaac, I understand what that the loop sets environment variables that init will inherit, but what's the purpose of the $@ at the end. It's now useless and init is going to wipe it out anyway. Did I miss something? Le 29/01/2016 17:50, Nicolas CARRIER a écrit : Is it even possible ? Won't it suffer from the lack of proc / sys and dev ? Environment variables setup by init ? What's more, there is a risk to spawn multiple processes (eval ?) before init is launched and the previous questions do apply. The first command in your script may be 'busybox mount -t proc proc /proc' . I don't think you need /sys and /dev. Mounting /sys is as easy as 'busybox mount -t sysfs sys /sys'. The processes created in the mean time have no consequence: you terminate your script with 'exec init'; this does not cause any fork. It is the same process which continues with the new init, and still pid1. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Fwd: why are init's arguments wiped ?
Le 01/02/2016 23:34, Mike Frysinger a écrit : On 01 Feb 2016 22:33, Didier Kryn wrote: Le 01/02/2016 18:10, Mike Frysinger a écrit : it makes a lot of sense when you fork children that have specific purposes. rather than just seeing the program's name 4 times, it's more helpful for them to be broken up. prctl() can be used for that, with the operation code PR_SET_NAME. It does not change the command line. right, but that has its own limitations: - it's new to linux-2.6.9 - can only set the name - is limited to 16 bytes - can't change command line args so we're still stuck with this behavior of modifying the argv mem directly :( -mike IIUC your argument was there's a need to give sensible names to children. prctl() allows this *without* resorting to modifying the command line args. I don't find 16 chars (in reality 15) is short for the purpose. Didier Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question on mdev's custom command invocation
Le 16/11/2016 18:37, Olivier Brunel a écrit : On Wed, 16 Nov 2016 16:27:12 +0100 Didier Kryn<k...@in2p3.fr> wrote: > Hello. > > I'm willing to create/delete symlinks in /dev/disk/by-uuid and >/dev/disk/by-label . For this, I've written a script and added the >following lines to /etc/mdev.conf: >sd[a-z][0-9]* root:disk 660 */sbin/mdev-disk >hd[a-z][0-9]* root:disk 660 */sbin/mdev-disk > > Note that I use /dev/mdev.seq to serialize events. > > Is there a means for my script mdev-disk to determine if the >device is being inserted or extracted? For example it would be easy >if mdev provided the uevent's action (add, remove) I'm assuming you already use environment variables in your script, e.g. $MDEV, $SEQNUM, etc Maybe you missed $ACTION, sounds like what you're looking for. Good to know that; https://git.busybox.net/busybox/plain/docs/mdev.txt only mentions $MDEV . Thanks a lot. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Question on mdev's custom command invocation
Le 17/11/2016 13:09, Peter Korsgaard a écrit : On Thu, Nov 17, 2016 at 11:02 AM, Didier Kryn <k...@in2p3.fr> wrote: I'm assuming you already use environment variables in your script, e.g. $MDEV, $SEQNUM, etc Maybe you missed $ACTION, sounds like what you're looking for. Good to know that; https://git.busybox.net/busybox/plain/docs/mdev.txt only mentions $MDEV . That is because those environment variables comes from the kernel when it invokes the hotplug helper (mdev): http://lxr.free-electrons.com/source/Documentation/driver-model/porting.txt#L375 I knew that of course, how else could it work! But I seem idiotic enough to not have even imagined that mdev passed all these variables to its child. Thanks all. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Question on mdev's custom command invocation
Hello. I'm willing to create/delete symlinks in /dev/disk/by-uuid and /dev/disk/by-label . For this, I've written a script and added the following lines to /etc/mdev.conf: sd[a-z][0-9]* root:disk 660 */sbin/mdev-disk hd[a-z][0-9]* root:disk 660 */sbin/mdev-disk Note that I use /dev/mdev.seq to serialize events. Is there a means for my script mdev-disk to determine if the device is being inserted or extracted? For example it would be easy if mdev provided the uevent's action (add, remove) My current trick is to create links when they don't exist and delete them when they exist, but it's far from rock-solid. Possible alternatives I see are: - use different commands for insertion and extraction - not sure mdev.conf allows to have two lines per device pattern - monitor /dev with inotify instead of using a command launched by mdev, but this process would be constantly there sleeping. Thanks for your help. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Race in reboot/poweroff path at init?
Le 11/10/2017 à 04:43, Jeremy Kerr a écrit : Hi Laurent, Thanks for the reply, good to get some conversation going here! - 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. 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? [Non-Linux platforms may not support the same abstract namespace, so I'd need to implement a fallback there, but I don't (yet) know if this same race is relevant on those platforms...] I'd rather not just wear the race, as that means we've missed shutdown events, which is quite user-visible. The signal-after-reaped-grandchild approach seems okay too, if other methods aren't workable. Or even Tito's suggestion of a repeated signal, which has the advantage of a minimal change to code. 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. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: BusyBox built-in shell (ash)
Le 13/12/2017 à 00:56, Mattias Schlenker a écrit : Am 13.12.2017 um 00:28 schrieb A.W.C.: Hi, yes, I know that Squashfs is read-only filesystem. Tried again, not sure what need be changed here for this specific configuration and filesystems available. # mknod -m 666 /dev/null c 1 3 mknod: /dev/null: Read-only file system # mknod -m 666 /dev/zero c 1 5 mknod: /dev/zero: Read-only file system # mkdir /dev/pts mkdir: cannot create directory '/dev/pts': Read-only file system # mount -t devtmpfs none /dev mount: mounting none on /dev failed: No such device RTFM, Read Those Fine Manuals. man mknod seems devtmpfs is not supported by your kernel. Create device nodes manually. Like back in 1998. Or mount /dev on tmpfs and use mdev. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
Le 12/02/2020 à 13:16, Eli Schwartz a écrit : On 2/12/20 6:07 AM, Didier Kryn wrote: FYI, there has been for decades an adduser in Debian which is higher level than useradd in the sense that it is a helper for admin. It enforces local policy and can be used to change it: minimum userid, default group, etc. Strange. Local policy via useradd is configured in /etc/login.defs If USERGROUPS_ENAB is defined as "yes", useradd will by default create a new group for each user, and add them to the group, and if it is defined as "no", then the GROUP setting in /etc/default/useradd (falling back to 100 by default) will be used as the GID which will be the newly created user's primary group. The minimum and maximum UID/GID pool is defined via this conf block: # # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 6 # System accounts SYS_UID_MIN 500 SYS_UID_MAX 999 # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 6 # System accounts SYS_GID_MIN 500 SYS_GID_MAX 999 ... I'm not sure what additional utility "adduser" would bring, given this is all already configurable. Well, I think there are more things configurable with adduser. And, by default, it enforces Debian policy. It always has been a problem for me to remember how it works and I always preferred useradd. And even using a hand-made script to implement my own defaults. Didier Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] bug #10981: adduser -D behavior
Le 11/02/2020 à 15:36, Eli Schwartz a écrit : On 2/11/20 8:13 AM, Donovan Keohane wrote: In adduser in coreutils, the behavior of --disabled-password sets the users hash in /etc/shadow to a single asterisk. It looks like busybox adduser '-D' option is supposed to be analogous to the behavior of coreutils '--disabled-password'. There is no coreutils "adduser" utility. util-linux does provide a "useradd" utility, but it does not have any --disabled-password option. On my Arch Linux system I cannot find any package which provides an "adduser" utility at all, except for busybox which provides some nonstandard applet in its multi-call binary, something the usual repository search tool cannot pick up. I would have expected busybox adduser -D (why does this exist in a form so different from the useradd command? At least it doesn't share the same name, that would be confusing... then again I guess that is why the unusual name) to do exactly what it I guess does, that is to say, it disables the feature of automatically prompting for a password, which means you will need to manually "passwd"/"chpasswd" in order to login. This emulates the default behavior of util-linux useradd, which creates an account with a disabled password, and expects you to passwd and change it. Is there a problem with this behavior? FYI, there has been for decades an adduser in Debian which is higher level than useradd in the sense that it is a helper for admin. It enforces local policy and can be used to change it: minimum userid, default group, etc. Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Non-responsive maintainer?
Le 08/06/2020 à 11:12, Denys Vlasenko a écrit : > Sorry guys, I indeed fell off the radar for too long! > I'm fine. > I'm getting on patch review right away! > SORRY!!! GREAT news, Denys! So many people, including lurkers like me, were afraid you were sick. (~: :~) Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] shrink last_char_is function even more
Le 20/07/2020 à 09:22, Laurent Bercot a écrit : > 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. There are two moments the error can be caught: at compile time, if the compiler can determine wether the pointer is null or not, or at run time if the previous is impossible. In the second case, the compiler should insert the defensive code by itself into the caller. It is always safer and more readable to establish this kind of contract and let the compiler take care of the defense. This kind of contract exists in other languages but I can't remember it in C. Is a non-null pointer a novelty of the C language or a gcc extension? Didier ___ 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?
Le 20/09/2023 à 07:51, Roberto A. Foglietta a écrit : The reason because it exists the ioctl() is well explained here https://stackoverflow.com/questions/17118705/using-rndaddentropy-to-add-entropy-to-dev-random which refers to the man page https://man7.org/linux/man-pages/man4/random.4.html Beware: I may have misunderstood something but the last reference must be outdated since it recommends to save the seed under /var/run ... In Debian/Devuan, /var/run points to /run which is mounted on tmpfs and therefore vanishes on shutdown. Better store the seed under /var/lib. It is the rationale of everything /run to be lost on reboot. /var/lib is not so well defined; it contains stuff which must be preserved (eg hardware clock frequency adjustment) and things which don't need (eg file locks). -- Didier ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
