From vda.linux at googlemail.com Thu Nov 1 11:54:47 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 1 Nov 2007 18:54:47 +0000 Subject: Plea to use STD{IN, OUT, ERR}_FILENO instead of constants [was: Re: svn commit: trunk/busybox/shell] In-Reply-To: <20071029211025.GE1869@aon.at> References: <20071029191731.44746A607D@busybox.net> <20071029211025.GE1869@aon.at> Message-ID: <200711011854.47854.vda.linux@googlemail.com> On Monday 29 October 2007 21:10, Bernhard Fischer wrote: > > #if ENABLE_ASH_READ_TIMEOUT > > if (ts.tv_sec || ts.tv_usec) { > >-// TODO: replace with poll, it is smaller > > FD_ZERO(&set); > > FD_SET(0, &set); > > It would be nice if (long-term) we could strive to use the respective > STD{IN,OUT,ERR}_FILENO defines for these. > > > >- i = select(FD_SETSIZE, &set, NULL, NULL, &ts); > >- if (!i) { > >+ /* poll-based wait produces bigger code, using select */ > >+ i = select(1, &set, NULL, NULL, &ts); > > likewise. > > PS: while for /me, it's perfectly clear what these usually boil down to, > it is more elaborate to read and easier to understand for beginners if > the defines are used. But more importantly, as Shaun Jackman and others > did point out more than once: > " > More importantly, it > allows a header to redefine STDIN_FILENO to fileno(stdin) so that > stdin may be replaced by a socket on a system that does not support > dup2. > " > So, IMHO, it's a matter of cleanlyness to use STD{IN,OUT,ERR}_FILENO > where possible. Ok, will gradually do that. -- vda From yann.morin.1998 at anciens.enib.fr Fri Nov 2 09:05:23 2007 From: yann.morin.1998 at anciens.enib.fr (Yann E. MORIN) Date: Fri, 2 Nov 2007 17:05:23 +0100 Subject: Question about insmod/busybox In-Reply-To: <472A2679.7040306@mvista.com> References: <472A2679.7040306@mvista.com> Message-ID: <200711021705.24080.yann.morin.1998@anciens.enib.fr> Hello Khem! Would have been great if you had CCed the busybox mailing list. :-| So first thing you have to know: I don't know much of the insmod code. I maintain the modprobe code when bugs arise, but insmod (at least for 2.4) is too complex for me (plus I don't use 2.4 any more, and 2.6 is clean). On Thursday 01 November 2007 20:18:17 Khem Raj wrote: > I have a question for you about busybox/insmod. I am modifying this so > that it can load more than one module in one invocation. > In such a scenario I get a kernel crash after a while when I try to > insmod 50 modules. > If I write a shell script which calls insmod 50 times to insert modules > one by one it works. That is exactly what I would have suggested: create a script that loops and calls insmod for each module. > The modification I do to the insmod is a wrapper which calls > insmod_ng_main () in a while loop and does the argv processing. I would say: don't do that, unless the real insmod understands more than one module as arguments, which I highly doubt. We try to maintain a compatible API between "original" applications and the corresponding applets in busybox. > In this scenario a kernel oops is triggered. > Now I want to know if insmod is written assuming that only 1 module is > installed in that case it will not free the malloc'ed memory and this is > being caused by memory leak or if there is real problem in kernel. Could well be that you did not activate CONFIG_FEATURE_CLEAN_UP or/ insmod does not cleanly handle memory. I guess Denys would be able to tell if insmod is NOFORK-clean. Denys? Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ?_? >==-- ?------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. | ?------------------------------?-------?------------------?--------------------? From vda.linux at googlemail.com Fri Nov 2 16:18:59 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 2 Nov 2007 23:18:59 +0000 Subject: Question about insmod/busybox In-Reply-To: <200711021705.24080.yann.morin.1998@anciens.enib.fr> References: <472A2679.7040306@mvista.com> <200711021705.24080.yann.morin.1998@anciens.enib.fr> Message-ID: <200711022319.00174.vda.linux@googlemail.com> On Friday 02 November 2007 16:05, Yann E. MORIN wrote: > Hello Khem! > > Would have been great if you had CCed the busybox mailing list. :-| > > So first thing you have to know: I don't know much of the insmod code. I > maintain the modprobe code when bugs arise, but insmod (at least for 2.4) > is too complex for me (plus I don't use 2.4 any more, and 2.6 is clean). > > On Thursday 01 November 2007 20:18:17 Khem Raj wrote: > > I have a question for you about busybox/insmod. I am modifying this so > > that it can load more than one module in one invocation. > > In such a scenario I get a kernel crash after a while when I try to > > insmod 50 modules. 2.4 insmod is big and complex. [taking a look, removing 0.5k of bloat] Since you are getting _kernel_ crash, obviously in your case you get corrupted data loaded into kernel. IOW: the module's images loaded by 50 successive insmods is different from images loaded by your modified insmod. You have two options: add hexdumping debug to all pieces of data loaded into kernel (you will need to instrument insmod for that), compare results of 50 insmods with results of modified-insmod-of-50-modules, and find out what is different. or use "50 insmods" approach, since you are likely to stop using 2.4 insmod anyway in a year or two. > > If I write a shell script which calls insmod 50 times to insert modules > > one by one it works. > > That is exactly what I would have suggested: create a script that loops > and calls insmod for each module. Yes. > > The modification I do to the insmod is a wrapper which calls > > insmod_ng_main () in a while loop and does the argv processing. Wait a second. Are you using _2.6_ insmod? It is very simple. > I would say: don't do that, unless the real insmod understands more than > one module as arguments, which I highly doubt. > > We try to maintain a compatible API between "original" applications and > the corresponding applets in busybox. > > > In this scenario a kernel oops is triggered. Well, the same idea holds, but you need to add debugging only in one place: len = MAXINT(ssize_t); map = xmalloc_open_read_close(filename, &len); /* print len, address and hex dump of bytes read */ ret = syscall(__NR_init_module, map, len, options); Check whether len, alignment or contents are changed. Sou probably also want to add some free() statements, insmod_ng_main() is rather careless with allocated memory. This does not explain kernel oops, though. > > Now I want to know if insmod is written assuming that only 1 module is > > installed in that case it will not free the malloc'ed memory and this is > > being caused by memory leak or if there is real problem in kernel. Memory leaks in userspace generally cannot cause kernel oopses. -- vda From marc.blumentritt at arcor.de Fri Nov 2 12:59:05 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Fri, 02 Nov 2007 20:59:05 +0100 Subject: Problem with PPID and bb grep Message-ID: Hi bb list, I'm working on my first embedded system, using Gentoo and of course busybox [1]. The complete root fs is placed in initramfs. During my work on this I stumbled about two things, which could be bugs of bb: 1.) I use an initialization script, which is called by init. This script starts with this: #!/bin/sh # Copyright 2006-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Ensure we are called by init echo "PPID = $PPID" #[ "$PPID" == "1" ] || exit 0 I would expect a PPID of 1, bit I get something like 833! But if a check with ps, init has PID of 1?! I cannot explain this. I also used sysvinit instead of bb init and checked PPID in a similar way and got the same result! The only idea I have, where this could come from is, that /bin/sh is of course a link to /bin/busybox. Perhaps this breaks checking PPID? Or this is some kind of bug? Or is this related with running a system in rootfs of initramfs? 2.) There seems to be a bug in bb grep. I did this on my machine: hive ~ # busybox grep -Fow usbfs /proc/filesystems Segmentation fault hive ~ # busybox grep -Fo usbfs /proc/filesystems Segmentation fault hive ~ # busybox grep -F usbfs /proc/filesystems nodev usbfs hive ~ # busybox grep -o usbfs /proc/filesystems usbfs hive ~ # busybox grep -w usbfs /proc/filesystems nodev usbfs hive ~ # busybox grep -ow usbfs /proc/filesystems usbfs hive ~ # busybox grep usbfs /proc/filesystems nodev usbfs The first two should certainly not result in a Segmentation fault, right? Thanks for busybox. It is really great! Regrads, Marc [1] http://article.gmane.org/gmane.linux.gentoo.embedded/1791 From natanael.copa at gmail.com Sat Nov 3 03:20:32 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Sat, 03 Nov 2007 11:20:32 +0100 Subject: Problem with PPID and bb grep In-Reply-To: References: Message-ID: <1194085232.596.3.camel@nc.nor.wtbts.org> On Fri, 2007-11-02 at 20:59 +0100, Marc Blumentritt wrote: > 2.) There seems to be a bug in bb grep. I did this on my machine: > > hive ~ # busybox grep -Fow usbfs /proc/filesystems > Segmentation fault I can reproduce this in svn version too. here is a backtrace: (gdb) bt #0 0x080f7c9a in grep_file (file=0x8143d58) at findutils/grep.c:277 #1 0x080f8231 in grep_main (argc=1, argv=0xffb1d6b8) at findutils/grep.c:525 #2 0x0806cf95 in run_appletstruct_and_exit (applet=0xffb1d6a8, argv=0x1) at libbb/appletlib.c:648 #3 0x0806cfd7 in run_applet_and_exit (name=0xffb1d7db "grep", argv=0xffb1d6a8) at libbb/appletlib.c:655 #4 0x0810b8d8 in ?? () #5 0x081433ec in ?? () #6 0x0806d1ad in run_applet_and_exit (name=0x812acdc "", argv=0x78b1d7c8) at libbb/appletlib.c:628 #7 0x0806d571 in main (argc=-5122440, argv=0xffb1d6a4) at libbb/appletlib.c:683 -nc From natanael.copa at gmail.com Sat Nov 3 03:57:49 2007 From: natanael.copa at gmail.com (Natanael Copa) Date: Sat, 03 Nov 2007 11:57:49 +0100 Subject: [PATCH] Re: Problem with PPID and bb grep In-Reply-To: References: Message-ID: <1194087469.596.8.camel@nc.nor.wtbts.org> On Fri, 2007-11-02 at 20:59 +0100, Marc Blumentritt wrote: > 2.) There seems to be a bug in bb grep. I did this on my machine: > hive ~ # busybox grep -Fo usbfs /proc/filesystems > Segmentation fault attatched patch should fix it (in svn). Should got to fixes-1.7.2 as well. while I was at it, I found another bug: # grep -Fw usb /proc/filesystems # busybox grep -Fw usb /proc/filesystems nodev usbfs but thats another story. -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-Fo.patch Type: text/x-patch Size: 1631 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20071103/e46ff9fd/attachment.bin From junk_mail at wp.pl Sat Nov 3 09:31:06 2007 From: junk_mail at wp.pl (dytu iuyr) Date: Sat, 03 Nov 2007 17:31:06 +0100 Subject: Problem with static ARP on router TP-Link TD8840 Message-ID: <472ca24ab6433@wp.pl> hello, My router TP-Link TD8840 uses Busybox v.1.00 and there is ARP tool on it. I can add new entry using: "arp add IP Adress MAC Adress". The problem is that I can't save that entry permanently. After rebooting that entry is missing... What am i doing wrong? Is it common problem of Busybox or maybe its only problem with my version of busybox and my arp applet? What can I do? Any help and ideas are welcomed ;) sly ---------------------------------------------------- Jasienica-powr?t! "Rzeczypospolita Obojga Narod?w" Paw?a Jasienicy ju? w ksi?garniach! http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Frzeczypospolita.html&sid=85 From Ralf.Friedl at online.de Sat Nov 3 09:53:31 2007 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Sat, 03 Nov 2007 17:53:31 +0100 Subject: Problem with static ARP on router TP-Link TD8840 In-Reply-To: <472ca24ab6433@wp.pl> References: <472ca24ab6433@wp.pl> Message-ID: <472CA78B.2070500@online.de> dytu iuyr wrote: > My router TP-Link TD8840 uses Busybox v.1.00 and there is ARP tool on > it. I can add new entry using: "arp add IP Adress MAC Adress". The > problem is that I can't save that entry permanently. After rebooting > that entry is missing... > What am i doing wrong? Is it common problem of Busybox or maybe its only > problem with my version of busybox and my arp applet? What can I do? > The "problem" is that you expect these settings to be permanent. You (hopefully) don't expect IP-adresses or routing entries to be permanent but use init scripts to set them up at boot time. You should do the same if you need permanent ARP entries. Regards Ralf Friedl From busybox at dpe.lusars.net Sat Nov 3 11:27:15 2007 From: busybox at dpe.lusars.net (Dave Edwards) Date: Sat, 3 Nov 2007 14:27:15 -0400 (EDT) Subject: Newbie patch Message-ID: While banging my head on something else (which ultimately turned out to be me misunderstanding about what field applet.h is alphabetized on... not the USE_ bit, but the actual applet name), I discovered (what I think is) a typo on the new-applet-HOWTO.txt file. Patch attached. -------------- next part -------------- Index: docs/new-applet-HOWTO.txt =================================================================== --- docs/new-applet-HOWTO.txt (revision 20355) +++ docs/new-applet-HOWTO.txt (working copy) @@ -40,12 +40,12 @@ */ #include "libbb.h" -#include "other.h" +//#include "other.h" int mu_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE; int mu_main(int argc, char **argv) { - int fd; + int fd, n; char mu; fd = xopen("/dev/random", O_RDONLY); @@ -123,7 +123,7 @@ Add the applet to Config.in in the chosen directory: -config CONFIG_MU +config MU bool "MU" default n help From vda.linux at googlemail.com Sat Nov 3 17:32:07 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 00:32:07 +0000 Subject: Problem with PPID and bb grep In-Reply-To: References: Message-ID: <200711040032.07869.vda.linux@googlemail.com> On Friday 02 November 2007 19:59, Marc Blumentritt wrote: > Hi bb list, > > #!/bin/sh > # Copyright 2006-2007 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > > # Ensure we are called by init > echo "PPID = $PPID" > #[ "$PPID" == "1" ] || exit 0 > > I would expect a PPID of 1, bit I get something like 833! But if a check > with ps, init has PID of 1?! I cannot explain this. I also used sysvinit > instead of bb init and checked PPID in a similar way and got the same > result! The only idea I have, where this could come from is, that > /bin/sh is of course a link to /bin/busybox. Perhaps this breaks > checking PPID? Or this is some kind of bug? Or is this related with > running a system in rootfs of initramfs? I think that your process gets started from a child if init, not an init itself. Do "ps -A" and send output to the list, and alsoo look up what process has PID 833. > 2.) There seems to be a bug in bb grep. I did this on my machine: > > hive ~ # busybox grep -Fow usbfs /proc/filesystems > Segmentation fault > hive ~ # busybox grep -Fo usbfs /proc/filesystems > Segmentation fault > hive ~ # busybox grep -F usbfs /proc/filesystems > nodev usbfs > hive ~ # busybox grep -o usbfs /proc/filesystems > usbfs > hive ~ # busybox grep -w usbfs /proc/filesystems > nodev usbfs > hive ~ # busybox grep -ow usbfs /proc/filesystems > usbfs > hive ~ # busybox grep usbfs /proc/filesystems > nodev usbfs > > The first two should certainly not result in a Segmentation fault, right? It's easier to track reports if you have one bug report per mail, not several unrelated bugs. Try attached patch. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 8.patch Type: text/x-diff Size: 1034 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20071104/93ba0c25/attachment.bin From vda.linux at googlemail.com Sat Nov 3 21:41:05 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 04:41:05 +0000 Subject: Newbie patch In-Reply-To: References: Message-ID: <200711040441.05611.vda.linux@googlemail.com> On Saturday 03 November 2007 18:27, Dave Edwards wrote: > While banging my head on something else (which ultimately turned out to be > me misunderstanding about what field applet.h is alphabetized on... not > the USE_ bit, but the actual applet name), I discovered (what > I think is) a typo on the new-applet-HOWTO.txt file. Patch attached. Applied, thanks -- vda From sync.jma at gmail.com Sun Nov 4 01:19:17 2007 From: sync.jma at gmail.com (Jun Ma) Date: Sun, 4 Nov 2007 16:19:17 +0800 Subject: e2fsck "permission denied" Message-ID: # # e2fsck /bin/ash: e2fsck: Permission denied # strace e2fsck execve("/bin/e2fsck", ["e2fsck"], [/* 7 vars */]) = -1 EACCES (Permission denied) write(2, "strace: exec: Permission denied\n", 32strace: exec: Permission denied ) = 32 exit(1) = ? Process 67 detached # ls -al /bin/e2fsck -rwxrwxr-x 1 root root 167552 Jan 1 2000 /bin/e2fsck # date Thu Jun 19 10:07:10 UTC 2003 I'm using busybox-1.7.1, the kernel comes up with init ramdisk as root filesystem, just confused... Any comments, thanks. -- I want to be an expert. I want to be a professional. From sync.jma at gmail.com Sun Nov 4 01:53:13 2007 From: sync.jma at gmail.com (Jun Ma) Date: Sun, 4 Nov 2007 16:53:13 +0800 Subject: e2fsck "permission denied" In-Reply-To: References: Message-ID: Sorry, I got the answer. My interpreter was wrong. "Requesting program interpreter: /usr/lib/libc.so.1", it should be "Requesting program interpreter: /lib/ld-uClibc.so.0". :) 2007/11/4, Jun Ma : > # > # e2fsck > /bin/ash: e2fsck: Permission denied > > # strace e2fsck > execve("/bin/e2fsck", ["e2fsck"], [/* 7 vars */]) = -1 EACCES > (Permission denied) > write(2, "strace: exec: Permission denied\n", 32strace: exec: Permission denied > ) = 32 > exit(1) = ? > Process 67 detached > > # ls -al /bin/e2fsck > -rwxrwxr-x 1 root root 167552 Jan 1 2000 /bin/e2fsck > > # date > Thu Jun 19 10:07:10 UTC 2003 > > I'm using busybox-1.7.1, the kernel comes up with init ramdisk as > root filesystem, just confused... > > Any comments, thanks. > > -- > I want to be an expert. > I want to be a professional. > -- I want to be an expert. I want to be a professional. From marc.blumentritt at arcor.de Sun Nov 4 04:07:57 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Sun, 04 Nov 2007 13:07:57 +0100 Subject: Problem with PPID In-Reply-To: <200711040032.07869.vda.linux@googlemail.com> References: <200711040032.07869.vda.linux@googlemail.com> Message-ID: Denys Vlasenko schrieb: > On Friday 02 November 2007 19:59, Marc Blumentritt wrote: >> Hi bb list, >> >> #!/bin/sh >> # Copyright 2006-2007 Gentoo Foundation >> # Distributed under the terms of the GNU General Public License v2 >> >> # Ensure we are called by init >> echo "PPID = $PPID" >> #[ "$PPID" == "1" ] || exit 0 >> >> I would expect a PPID of 1, bit I get something like 833! But if a check >> with ps, init has PID of 1?! I cannot explain this. I also used sysvinit >> instead of bb init and checked PPID in a similar way and got the same >> result! The only idea I have, where this could come from is, that >> /bin/sh is of course a link to /bin/busybox. Perhaps this breaks >> checking PPID? Or this is some kind of bug? Or is this related with >> running a system in rootfs of initramfs? > > I think that your process gets started from a child if init, not > an init itself. Do "ps -A" and send output to the list, > and alsoo look up what process has PID 833. This is ps -A from booted system: root at mediamachine $ ps -A PID USER COMMAND 1 root init 2 root [kthreadd] 3 root [migration/0] 4 root [ksoftirqd/0] 5 root [events/0] 6 root [khelper] 34 root [kblockd/0] 35 root [kacpid] 36 root [kacpi_notify] 124 root [ksuspend_usbd] 127 root [khubd] 129 root [kseriod] 144 root [pdflush] 145 root [pdflush] 146 root [kswapd0] 147 root [aio/0] 148 root [jfsIO] 149 root [jfsCommit] 150 root [jfsSync] 151 root [xfslogd/0] 152 root [xfsdatad/0] 824 root [kpsmoused] 1222 root syslogd 1352 root /usr/sbin/dropbear 1359 root /sbin/getty 38400 tty1 1360 root /sbin/getty 38400 tty2 1362 root /sbin/getty 38400 tty3 1363 root /sbin/getty 38400 tty4 1364 root /sbin/getty 38400 tty5 1371 root /sbin/getty 38400 tty6 1375 root /usr/sbin/dropbear 1376 root -sh 1381 root ps -A I do not see PID 833. I also added ps -a > /ps_init_data to my init script and got this result(!): root at mediamachine $ cat /ps_init_data PID USER COMMAND Empty list? At least init should be listed, shouldn't it? I'm also checking the PPID of my shutdown script. It was 1384 , but I think this depends upon how many commands I executed before (I did the cat command and reboot). Could it be, that busybox init creates a child process for every action it does? Regards, Marc From marc.blumentritt at arcor.de Sun Nov 4 04:10:42 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Sun, 04 Nov 2007 13:10:42 +0100 Subject: Problem with bb grep In-Reply-To: <200711040032.07869.vda.linux@googlemail.com> References: <200711040032.07869.vda.linux@googlemail.com> Message-ID: Denys Vlasenko schrieb: >> 2.) There seems to be a bug in bb grep. I did this on my machine: >> >> hive ~ # busybox grep -Fow usbfs /proc/filesystems >> Segmentation fault >> hive ~ # busybox grep -Fo usbfs /proc/filesystems >> Segmentation fault >> hive ~ # busybox grep -F usbfs /proc/filesystems >> nodev usbfs >> hive ~ # busybox grep -o usbfs /proc/filesystems >> usbfs >> hive ~ # busybox grep -w usbfs /proc/filesystems >> nodev usbfs >> hive ~ # busybox grep -ow usbfs /proc/filesystems >> usbfs >> hive ~ # busybox grep usbfs /proc/filesystems >> nodev usbfs >> >> The first two should certainly not result in a Segmentation fault, right? > > It's easier to track reports if you have one bug report per mail, > not several unrelated bugs. > > Try attached patch. It does not work on my system (s. attached file). I'm using busybox-1.7.2 on Gentoo. What could be wrong? Regards, Marc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8.patch-32068.out Url: http://busybox.net/lists/busybox/attachments/20071104/d9973697/attachment.diff From vda.linux at googlemail.com Sun Nov 4 05:56:53 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 13:56:53 +0000 Subject: Problem with PPID In-Reply-To: References: <200711040032.07869.vda.linux@googlemail.com> Message-ID: <200711041356.53769.vda.linux@googlemail.com> On Sunday 04 November 2007 12:07, Marc Blumentritt wrote: > >> # Ensure we are called by init > >> echo "PPID = $PPID" > >> #[ "$PPID" == "1" ] || exit 0 > >> > >> I would expect a PPID of 1, bit I get something like 833! But if a check > >> with ps, init has PID of 1?! I cannot explain this. I also used sysvinit > >> instead of bb init and checked PPID in a similar way and got the same > >> result! The only idea I have, where this could come from is, that > >> /bin/sh is of course a link to /bin/busybox. Perhaps this breaks > >> checking PPID? Or this is some kind of bug? Or is this related with > >> running a system in rootfs of initramfs? > > > > I think that your process gets started from a child of init, not > > from init itself. Do "ps -A" and send output to the list, > > and alsoo look up what process has PID 833. > > This is ps -A from booted system: > root at mediamachine $ ps -A > PID USER COMMAND > 1 root init > 2 root [kthreadd] ... > 1381 root ps -A > > I do not see PID 833. > > I also added > ps -a > /ps_init_data to my init script Yes, this is what I meant to do. > and got this result(!): > root at mediamachine $ cat /ps_init_data > PID USER COMMAND > > Empty list? At least init should be listed, shouldn't it? If /proc is not mounted, ps cannot retrieve process list. Mount /proc first: mount -t proc proc /proc ps -a > /ps_init_data -- vda From vda.linux at googlemail.com Sun Nov 4 06:09:42 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 14:09:42 +0000 Subject: Problem with bb grep In-Reply-To: References: <200711040032.07869.vda.linux@googlemail.com> Message-ID: <200711041409.42594.vda.linux@googlemail.com> On Sunday 04 November 2007 12:10, Marc Blumentritt wrote: > > Try attached patch. > > It does not work on my system (s. attached file). I'm using > busybox-1.7.2 on Gentoo. What could be wrong? Try this one, it is rediffed against 1.7.2 -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: busybox-1.7.2-grep.patch Type: text/x-diff Size: 1274 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20071104/d3441699/attachment-0001.bin From vda.linux at googlemail.com Sun Nov 4 07:40:53 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 15:40:53 +0000 Subject: busybox 1.7.3 and busybox 1.8.0 are released Message-ID: <200711041540.53648.vda.linux@googlemail.com> Hi, busybox 1.7.3 and busybox 1.8.0 are released. It may take an hour or so for 1.8.0 announcemet to appear on busybox.net start page. Big thanks for all bug reporters and patch submitters! -- vda From marc.blumentritt at arcor.de Sun Nov 4 09:51:44 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Sun, 04 Nov 2007 18:51:44 +0100 Subject: Problem with bb grep In-Reply-To: <200711041409.42594.vda.linux@googlemail.com> References: <200711040032.07869.vda.linux@googlemail.com> <200711041409.42594.vda.linux@googlemail.com> Message-ID: Denys Vlasenko schrieb: > On Sunday 04 November 2007 12:10, Marc Blumentritt wrote: >>> Try attached patch. >> It does not work on my system (s. attached file). I'm using >> busybox-1.7.2 on Gentoo. What could be wrong? > > Try this one, it is rediffed against 1.7.2 This one worked for me and solved my problem! Thanks Marc From marc.blumentritt at arcor.de Sun Nov 4 09:54:00 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Sun, 04 Nov 2007 18:54:00 +0100 Subject: Problem with PPID In-Reply-To: <200711041356.53769.vda.linux@googlemail.com> References: <200711040032.07869.vda.linux@googlemail.com> <200711041356.53769.vda.linux@googlemail.com> Message-ID: Denys Vlasenko schrieb: > On Sunday 04 November 2007 12:07, Marc Blumentritt wrote: > > mount -t proc proc /proc > ps -a > /ps_init_data Now I have these results: root at mediamachine $ cat /ps_init_data PID USER COMMAND 1 root init 2 root [kthreadd] 3 root [migration/0] 4 root [ksoftirqd/0] 5 root [events/0] 6 root [khelper] 34 root [kblockd/0] 35 root [kacpid] 36 root [kacpi_notify] 124 root [ksuspend_usbd] 127 root [khubd] 129 root [kseriod] 144 root [pdflush] 145 root [pdflush] 146 root [kswapd0] 147 root [aio/0] 148 root [jfsIO] 149 root [jfsCommit] 150 root [jfsSync] 151 root [xfslogd/0] 152 root [xfsdatad/0] 824 root [kpsmoused] 833 root init 834 root /bin/sh /sbin/rc.init 836 root ps -A Is this the expected result, that init starts first a child of itself, which then starts my init script rc.init? Regards Marc From vda.linux at googlemail.com Sun Nov 4 12:59:04 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 4 Nov 2007 20:59:04 +0000 Subject: Problem with PPID In-Reply-To: References: <200711041356.53769.vda.linux@googlemail.com> Message-ID: <200711042059.04533.vda.linux@googlemail.com> On Sunday 04 November 2007 17:54, Marc Blumentritt wrote: > Denys Vlasenko schrieb: > > On Sunday 04 November 2007 12:07, Marc Blumentritt wrote: > > > > mount -t proc proc /proc > > ps -a > /ps_init_data > > Now I have these results: > root at mediamachine $ cat /ps_init_data > PID USER COMMAND > 1 root init > 2 root [kthreadd] > 3 root [migration/0] > 4 root [ksoftirqd/0] > 5 root [events/0] > 6 root [khelper] > 34 root [kblockd/0] > 35 root [kacpid] > 36 root [kacpi_notify] > 124 root [ksuspend_usbd] > 127 root [khubd] > 129 root [kseriod] > 144 root [pdflush] > 145 root [pdflush] > 146 root [kswapd0] > 147 root [aio/0] > 148 root [jfsIO] > 149 root [jfsCommit] > 150 root [jfsSync] > 151 root [xfslogd/0] > 152 root [xfsdatad/0] > 824 root [kpsmoused] > 833 root init > 834 root /bin/sh /sbin/rc.init > 836 root ps -A > > Is this the expected result, that init starts first a child of itself, > which then starts my init script rc.init? Apparently yes. It happens in init/init.c, in this function: static pid_t run(const struct init_action *a) I think it should be either explained in detail in the comments, or simplified. -- vda From busybox at dpe.lusars.net Sun Nov 4 19:53:20 2007 From: busybox at dpe.lusars.net (Dave Edwards) Date: Sun, 4 Nov 2007 22:53:20 -0500 (EST) Subject: Patch to nc Message-ID: I've written a small patch for nc. It adds a switch that causes nc to return after the first read from network (instead of establishing a connection). Why this is useful for me (and potentially others): Some network protocols (such as Tivo's home networking protocols) use a periodic broadcast UDP message as a service locator (a "beacon"). The existing 'nc' will block after the first such packet, expecting a UDP session to be established. This patch adds a switch to tell it to write out the contents of the buffer and return immediately. I used the '-O' ('Oh', not 'zero') flag, for 'Only one packet', which is (as far as I can tell) currently unused by both the BusyBox 'nc' and the BSD 'nc'. It's enabled as part of the "USE_NC_EXTRA" ifdef. Example: $ ./busybox nc -l -u -v -p 2190 listening on [::]:2190 ... connect to 192.168.1.255:2190 from TiVo:2190 ([::ffff:192.168.1.31]:2190) tivoconnect=1 swversion=9.1-01-2-140 method=broadcast identity=240000080XXXXXX machine=Living Room platform=tcd/Series2 services=TiVoMediaServer:80/http [ ... time passes ... ] punt! [ I ^C busybox ] $ ./busybox nc -l -u -O -v -p 2190 listening on [::]:2190 ... connect to 192.168.1.255:2190 from TiVo:2190 ([::ffff:192.168.1.31]:2190) tivoconnect=1 swversion=9.1-01-2-140 method=broadcast identity=240000080XXXXXX machine=Living Room platform=tcd/Series2 services=TiVoMediaServer:80/http $ -------------- next part -------------- Index: networking/nc_bloaty.c =================================================================== --- networking/nc_bloaty.c (revision 20365) +++ networking/nc_bloaty.c (working copy) @@ -1,3 +1,4 @@ +/* vi: set sw=4 ts=4: */ /* Based on netcat 1.10 RELEASE 960320 written by hobbit at avian.org. * Released into public domain by the author. * @@ -129,6 +130,7 @@ OPT_i = (1 << (7+ENABLE_NC_SERVER)) * ENABLE_NC_EXTRA, OPT_o = (1 << (8+ENABLE_NC_SERVER)) * ENABLE_NC_EXTRA, OPT_z = (1 << (9+ENABLE_NC_SERVER)) * ENABLE_NC_EXTRA, + OPT_O = (1 << (10+ENABLE_NC_SERVER)) * ENABLE_NC_EXTRA, }; #define o_nflag (option_mask32 & OPT_n) @@ -141,9 +143,11 @@ #if ENABLE_NC_EXTRA #define o_ofile (option_mask32 & OPT_o) #define o_zero (option_mask32 & OPT_z) +#define o_onlyone (option_mask32 & OPT_O) #else #define o_ofile 0 #define o_zero 0 +#define o_onlyone 0 #endif /* Debug: squirt whatever message and sleep a bit so we can see it go by. */ @@ -584,6 +588,16 @@ } else { rnleft = rr; np = bigbuf_net; +#if ENABLE_NC_EXTRA + /* The following is a special case intended mostly for UDP listeners, + * where the contents of the first packet get printed and then the + * connection gets closed. Useful for tracking broadcast UDP beacons. */ + if(o_onlyone) { /* Special case where we just want the first packet */ + rr = write(1, np, rnleft); /* don't care what write returns */ + close(netfd); + return 0; + } +#endif } Debug("got %d from the net, errno %d", rr, errno); } /* net:ding */ @@ -707,7 +721,7 @@ // -g -G -t -r deleted, unimplemented -a deleted too opt_complementary = "?2:vv"; /* max 2 params, -v is a counter */ getopt32(argv, "hnp:s:uvw:" USE_NC_SERVER("l") - USE_NC_EXTRA("i:o:z"), + USE_NC_EXTRA("i:o:zO"), &str_p, &str_s, &str_w USE_NC_EXTRA(, &str_i, &str_o, &o_verbose)); argv += optind; Index: include/usage.h =================================================================== --- include/usage.h (revision 20365) +++ include/usage.h (working copy) @@ -2494,6 +2494,7 @@ USE_NC_EXTRA( \ "\n (use -l twice with -e for persistent server)") \ "\n -p PORT Local port number" \ + "\n -O Only print the first packet, then exit (use with -l)"\ ) #define nc_notes_usage "" \ From Ralf.Friedl at online.de Mon Nov 5 03:55:55 2007 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Mon, 05 Nov 2007 12:55:55 +0100 Subject: Ash + telnetd: telnet client hangs after exit In-Reply-To: <200710162228.40601.vda.linux@googlemail.com> References: <470EDD1D.2090201@Kriegisch.name> <200710152155.55259.vda.linux@googlemail.com> <4714914F.4020508@online.de> <200710162228.40601.vda.linux@googlemail.com> Message-ID: <472F04CB.4000504@online.de> Hi I found some more problems with the current telnetd code (I'm sorry that I didn't notice them earlier). The bigger problem is that without the option -K, telnetd will never wait for its children, leaving them as zombies. A minor problem is that it is possible, although unlikely, that two children exit at the same time. Or more exactly, it is possible that one child exits, which raises SIGCHLD for telnetd. If another child exits after the first, but before the signal was delivered, the signal handler will be called only once, not twice for the two children. If the system is heavy loaded, maybe parts of telnetd paged out, this time may be log enough for this to happen. It is unlikely to happen with telnetd, but I already had this problem with a mail server in real life. The solution is to loop in the signal handler until wait finds no more children. I also changed the argument to waitpid from &sig to NULL because "man waitpid" says: "If status is not NULL, wait or waitpid store ...", because the status is not used. Regards Ralf Friedl --- networking/telnetd.c +++ networking/telnetd.c @@ -384,13 +384,17 @@ pid_t pid; struct tsession *ts; - pid = waitpid(-1, &sig, WNOHANG); - if (pid > 0) { + for (;;) { + pid = waitpid(-1, NULL, WNOHANG); + if (pid <= 0) + break; + if (!(option_mask32 & OPT_WATCHCHILD)) + continue; ts = sessions; while (ts) { if (ts->shell_pid == pid) { ts->shell_pid = -1; - return; + break; } ts = ts->next; } @@ -464,8 +468,7 @@ /* We don't want to die if just one session is broken */ signal(SIGPIPE, SIG_IGN); - if (opt & OPT_WATCHCHILD) - signal(SIGCHLD, handle_sigchld); + signal(SIGCHLD, handle_sigchld); /* This is how the buffers are used. The arrows indicate the movement From vda.linux at googlemail.com Mon Nov 5 07:31:57 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Nov 2007 15:31:57 +0000 Subject: Ash + telnetd: telnet client hangs after exit In-Reply-To: <472F04CB.4000504@online.de> References: <470EDD1D.2090201@Kriegisch.name> <200710162228.40601.vda.linux@googlemail.com> <472F04CB.4000504@online.de> Message-ID: <200711051531.57515.vda.linux@googlemail.com> On Monday 05 November 2007 11:55, Ralf Friedl wrote: > Hi > > I found some more problems with the current telnetd code (I'm sorry that > I didn't notice them earlier). > > The bigger problem is that without the option -K, telnetd will never > wait for its children, leaving them as zombies. > > A minor problem is that it is possible, although unlikely, that two > children exit at the same time. Or more exactly, it is possible that one > child exits, which raises SIGCHLD for telnetd. If another child exits > after the first, but before the signal was delivered, the signal handler > will be called only once, not twice for the two children. > If the system is heavy loaded, maybe parts of telnetd paged out, this > time may be log enough for this to happen. > It is unlikely to happen with telnetd, but I already had this problem > with a mail server in real life. The solution is to loop in the signal > handler until wait finds no more children. > > I also changed the argument to waitpid from &sig to NULL because "man > waitpid" says: "If status is not NULL, wait or waitpid store ...", > because the status is not used. Thanks for the patch. Please review attached version. I noticed another bug: we do not restore SIGCHLD/SIGPIPE to default. As to "zombies created without -K" problem, I guess signal(SIGCHLD, SIG_IGN); will prevent that, no need to have handler installed/called. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.patch Type: text/x-diff Size: 3639 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20071105/52dd0d19/attachment.bin From Ralf.Friedl at online.de Mon Nov 5 08:03:25 2007 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Mon, 05 Nov 2007 17:03:25 +0100 Subject: Ash + telnetd: telnet client hangs after exit In-Reply-To: <200711051531.57515.vda.linux@googlemail.com> References: <470EDD1D.2090201@Kriegisch.name> <200710162228.40601.vda.linux@googlemail.com> <472F04CB.4000504@online.de> <200711051531.57515.vda.linux@googlemail.com> Message-ID: <472F3ECD.7050206@online.de> Denys Vlasenko wrote: > I noticed another bug: we do not restore SIGCHLD/SIGPIPE to default. > > As to "zombies created without -K" problem, I guess > signal(SIGCHLD, SIG_IGN); > will prevent that, no need to have handler installed/called. > Ignoring SIGCHLD should work. According to the man page, on execve() signals set to be caught are reset to default, while SIGCHLD set to SIG_IGN is undefined. The behavior of other signals set to SIG_IGN is not even mentioned, so restoring them to default is the safe solution. Regards Ralf Friedl From marc.blumentritt at arcor.de Mon Nov 5 08:29:20 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Mon, 05 Nov 2007 17:29:20 +0100 Subject: Problem with PPID In-Reply-To: <200711042059.04533.vda.linux@googlemail.com> References: <200711041356.53769.vda.linux@googlemail.com> <200711042059.04533.vda.linux@googlemail.com> Message-ID: Denys Vlasenko schrieb: > On Sunday 04 November 2007 17:54, Marc Blumentritt wrote: >> Denys Vlasenko schrieb: >>> On Sunday 04 November 2007 12:07, Marc Blumentritt wrote: >>> >>> mount -t proc proc /proc >>> ps -a > /ps_init_data >> Now I have these results: >> root at mediamachine $ cat /ps_init_data >> PID USER COMMAND >> 1 root init [...] >> 824 root [kpsmoused] >> 833 root init >> 834 root /bin/sh /sbin/rc.init >> 836 root ps -A >> >> Is this the expected result, that init starts first a child of itself, >> which then starts my init script rc.init? > > Apparently yes. It happens in init/init.c, in this function: > > static pid_t run(const struct init_action *a) > > I think it should be either explained in detail in the comments, > or simplified. If you mean simplified by not creating first a child of init, I'm right for it, since then system init scripts can check in a simple way, if they are started by init or not. Anyway, I know now where this PPID comes from, so thanks for your help. Regards, Marc From pgf at brightstareng.com Mon Nov 5 08:39:29 2007 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 05 Nov 2007 11:39:29 -0500 Subject: insmod error message Message-ID: <375.1194280769@brightstareng.com> insmod.c contains the following code (near end of file, if you're looking): ... ret = syscall(__NR_init_module, map, len, options); if (ret != 0) { bb_perror_msg_and_die("cannot insert '%s': %s (%li)", filename, moderror(errno), ret); } is the return value from a failed __NR_init_module actually useful? it looks more like leftover debugging output. paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Mon Nov 5 08:54:17 2007 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 05 Nov 2007 11:54:17 -0500 Subject: buglet in swapon with very large files Message-ID: <794.1194281657@brightstareng.com> hi -- one of our team found this while experimenting with a very large swap file. the symptom is that the file is rejected as having holes, when it does not (because the size goes negative). he did this some time ago, and i haven't tried to reproduce it since, but the fix looks correct, and moreover, benign. i'll commit in a day or two if there are no objections. paul diff -u -r1.1 swaponoff.c --- util-linux/swaponoff.c 5 Nov 2007 13:45:41 -0000 1.1 +++ util-linux/swaponoff.c 5 Nov 2007 16:52:38 -0000 @@ -21,7 +21,7 @@ #if ENABLE_DESKTOP /* test for holes */ if (S_ISREG(st.st_mode)) - if (st.st_blocks * 512 < st.st_size) + if (st.st_blocks * 512u < st.st_size) bb_error_msg("warning: swap file has holes"); #endif =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Mon Nov 5 09:00:01 2007 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 05 Nov 2007 12:00:01 -0500 Subject: flush typeahead in login Message-ID: <1398.1194282001@brightstareng.com> when getty emits its first prompt, it flushes typeahead beforehand. login (which emits the later prompts) does not. any reason is shouldn't? paul --- loginutils/login.c 5 Nov 2007 13:45:40 -0000 1.1 +++ loginutils/login.c 5 Nov 2007 16:59:40 -0000 @@ -291,6 +291,10 @@ openlog(applet_name, LOG_PID | LOG_CONS | LOG_NOWAIT, LOG_AUTH); while (1) { + + /* flush away any type-ahead (as getty does) */ + (void) ioctl(0, TCFLSH, TCIFLUSH); + if (!username[0]) get_username_or_die(username, sizeof(username)); =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Mon Nov 5 09:14:49 2007 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 05 Nov 2007 12:14:49 -0500 Subject: udhcpc retry interval Message-ID: <2490.1194282889@brightstareng.com> when udhcpc fails to get a lease, it waits a full minute before trying again. in some cases this is far too long. clearly the udhcpc commandline is becoming over-burdened, but without a config file, there's not much choice: i'd like to add an option (i chose '-A', for "again") which lets one set the try-again value. Index: networking/udhcp/dhcpc.c =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 dhcpc.c --- networking/udhcp/dhcpc.c 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ networking/udhcp/dhcpc.c 5 Nov 2007 17:13:59 -0000 @@ -144,7 +144,7 @@ int udhcpc_main(int argc, char **argv) { uint8_t *temp, *message; - char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_t; + char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_A, *str_t; uint32_t xid = 0; uint32_t lease = 0; /* can be given as 32-bit quantity */ unsigned t1 = 0, t2 = 0; /* what a wonderful names */ @@ -179,6 +179,7 @@ OPT_t = 1 << 16, OPT_v = 1 << 17, OPT_S = 1 << 18, + OPT_A = 1 << 19, }; #if ENABLE_GETOPT_LONG static const char udhcpc_longopts[] ALIGN1 = @@ -200,6 +201,7 @@ "timeout\0" Required_argument "T" "version\0" No_argument "v" "retries\0" Required_argument "t" + "tryagain\0" Required_argument "A" "syslog\0" No_argument "S" ; #endif @@ -208,6 +210,7 @@ client_config.script = DEFAULT_SCRIPT; client_config.retries = 3; client_config.timeout = 3; + client_config.tryagain = 60; /* Parse command line */ opt_complementary = "c--C:C--c" // mutually exclusive @@ -215,10 +218,10 @@ #if ENABLE_GETOPT_LONG applet_long_options = udhcpc_longopts; #endif - opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vS", + opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:A:t:vS", &str_c, &str_V, &str_h, &str_h, &str_F, &client_config.interface, &client_config.pidfile, &str_r, - &client_config.script, &str_T, &str_t + &client_config.script, &str_T, &str_A, &str_t ); if (opt & OPT_c) @@ -259,6 +262,8 @@ client_config.timeout = xatoi_u(str_T); if (opt & OPT_t) client_config.retries = xatoi_u(str_t); + if (opt & OPT_A) + client_config.tryagain = xatoi_u(str_A); if (opt & OPT_v) { puts("version "BB_VER); return 0; @@ -355,7 +360,7 @@ } /* wait to try again */ packet_num = 0; - timeout = now + 60; + timeout = now + client_config.tryagain; } break; case RENEW_REQUESTED: Index: networking/udhcp/dhcpc.h =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 dhcpc.h --- networking/udhcp/dhcpc.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ networking/udhcp/dhcpc.h 5 Nov 2007 17:13:59 -0000 @@ -30,6 +30,7 @@ int ifindex; /* Index number of the interface to use */ int retries; /* Max number of request packets */ int timeout; /* Number of seconds to try to get a lease */ + int tryagain; /* Seconds to wait after failure */ uint8_t arp[6]; /* Our arp address */ }; Index: include/usage.h =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/include/usage.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 usage.h --- include/usage.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ include/usage.h 5 Nov 2007 17:13:59 -0000 @@ -3835,6 +3835,8 @@ "\n -r,--request=IP IP address to request" \ "\n -s,--script=file Run file at dhcp events (default: /usr/share/udhcpc/default.script)" \ "\n -t,--retries=N Send up to N request packets"\ + "\n -T,--timeout=N Try to get a lease for N seconds (default: 3)"\ + "\n -A,--tryagain=N Wait N seconds (default: 60) after failure"\ "\n -f,--foreground Run in foreground" \ "\n -b,--background Background if lease cannot be immediately negotiated" \ "\n -S,--syslog Log to syslog too" \ =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Mon Nov 5 11:27:41 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 5 Nov 2007 19:27:41 +0000 Subject: buglet in swapon with very large files In-Reply-To: <794.1194281657@brightstareng.com> References: <794.1194281657@brightstareng.com> Message-ID: <200711051927.41203.vda.linux@googlemail.com> On Monday 05 November 2007 16:54, Paul Fox wrote: > hi -- > > one of our team found this while experimenting with a very large > swap file. the symptom is that the file is rejected as having > holes, when it does not (because the size goes negative). he did > this some time ago, and i haven't tried to reproduce it since, > but the fix looks correct, and moreover, benign. > > i'll commit in a day or two if there are no objections. > if (S_ISREG(st.st_mode)) > - if (st.st_blocks * 512 < st.st_size) > + if (st.st_blocks * 512u < st.st_size) > bb_error_msg("warning: swap file has holes"); I am committing a change where 512 is casted to off_t. -- vda From vda.linux at googlemail.com Mon Nov 5 17:56:00 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 Nov 2007 01:56:00 +0000 Subject: insmod error message In-Reply-To: <375.1194280769@brightstareng.com> References: <375.1194280769@brightstareng.com> Message-ID: <200711060156.01245.vda.linux@googlemail.com> On Monday 05 November 2007 16:39, Paul Fox wrote: > insmod.c contains the following code (near end of file, if you're looking): > ... > ret = syscall(__NR_init_module, map, len, options); > if (ret != 0) { > bb_perror_msg_and_die("cannot insert '%s': %s (%li)", > filename, moderror(errno), ret); > } > > is the return value from a failed __NR_init_module actually useful? > it looks more like leftover debugging output. Indeed it is. Removing it. -- vda From iali at ayesoft.com Tue Nov 6 03:39:05 2007 From: iali at ayesoft.com (Syed Irfan Ali Zaidi) Date: Tue, 6 Nov 2007 06:39:05 -0500 (EST) Subject: Tab key in busybox shell Message-ID: <48877.203.82.50.58.1194349145.squirrel@wm5> Hi, I have compiled a lattest version of busybox i-e 1.8.0. And when i execute it, it does not behave like a shell in the linux distribution. In linux shell, when we want to execute a command, we write the starting characters of the command and then use a tab key it either completes the command or displays the commnads thats start with the same characters. Then we choose from the output which command we want to use. But in this compiled version of busybox, when i use tab key on the shell, it does'nt do the search instead it behavious like a normal tab key that is it moves the cursor eight spaces ahead. Older versions of busybox had this feature. To enable this, are there any options for this feature? or Is this feature is not supported any more? What do i do? I am waiting for ur early response Thanks From vda.linux at googlemail.com Tue Nov 6 06:12:55 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 6 Nov 2007 14:12:55 +0000 Subject: Tab key in busybox shell In-Reply-To: <48877.203.82.50.58.1194349145.squirrel@wm5> References: <48877.203.82.50.58.1194349145.squirrel@wm5> Message-ID: <200711061412.55427.vda.linux@googlemail.com> On Tuesday 06 November 2007 11:39, Syed Irfan Ali Zaidi wrote: > Hi, > I have compiled a lattest version of busybox i-e 1.8.0. And when i execute > it, it does not behave like a shell in the linux distribution. > In linux shell, when we want to execute a command, we write the starting > characters of the command and then use a tab key it either completes the > command or displays the commnads thats start with the same characters. > Then we choose from the output which command we want to use. > But in this compiled version of busybox, when i use tab key on the shell, > it does'nt do the search instead it behavious like a normal tab key that > is it moves the cursor eight spaces ahead. Older versions of busybox had > this feature. To enable this, are there any options for this feature? or > Is this feature is not supported any more? What do i do? You need to select CONFIG_FEATURE_TAB_COMPLETION=y and maybe CONFIG_FEATURE_USERNAME_COMPLETION=y too. -- vda From wharms at bfs.de Tue Nov 6 08:55:29 2007 From: wharms at bfs.de (walter harms) Date: Tue, 06 Nov 2007 17:55:29 +0100 Subject: ash idle timeout ? Message-ID: <47309C81.7020101@bfs.de> hi list, does the ash have an idle timeout ? (if not it would be a nice enhancement :) re, wh From pgf at brightstareng.com Tue Nov 6 09:04:28 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 06 Nov 2007 12:04:28 -0500 Subject: udhcpc retry interval In-Reply-To: pgf's message of Mon, 05 Nov 2007 12:14:49 -0500. <2490.1194282889@brightstareng.com> Message-ID: <8092.1194368668@brightstareng.com> > when udhcpc fails to get a lease, it waits a full minute before > trying again. in some cases this is far too long. clearly > the udhcpc commandline is becoming over-burdened, but without > a config file, there's not much choice: i'd like to add > an option (i chose '-A', for "again") which lets one set the > try-again value. this patch is incorrect. don't apply, please. (i botched the getopt calls during a minor reword before posting. sigh.) paul > > Index: networking/udhcp/dhcpc.c > =================================================================== > RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.c,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 dhcpc.c > --- networking/udhcp/dhcpc.c 5 Nov 2007 13:45:42 -0000 1.1.1.1 > +++ networking/udhcp/dhcpc.c 5 Nov 2007 17:13:59 -0000 > @@ -144,7 +144,7 @@ > int udhcpc_main(int argc, char **argv) > { > uint8_t *temp, *message; > - char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_t; > + char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_A, *str_t; > uint32_t xid = 0; > uint32_t lease = 0; /* can be given as 32-bit quantity */ > unsigned t1 = 0, t2 = 0; /* what a wonderful names */ > @@ -179,6 +179,7 @@ > OPT_t = 1 << 16, > OPT_v = 1 << 17, > OPT_S = 1 << 18, > + OPT_A = 1 << 19, > }; > #if ENABLE_GETOPT_LONG > static const char udhcpc_longopts[] ALIGN1 = > @@ -200,6 +201,7 @@ > "timeout\0" Required_argument "T" > "version\0" No_argument "v" > "retries\0" Required_argument "t" > + "tryagain\0" Required_argument "A" > "syslog\0" No_argument "S" > ; > #endif > @@ -208,6 +210,7 @@ > client_config.script = DEFAULT_SCRIPT; > client_config.retries = 3; > client_config.timeout = 3; > + client_config.tryagain = 60; > > /* Parse command line */ > opt_complementary = "c--C:C--c" // mutually exclusive > @@ -215,10 +218,10 @@ > #if ENABLE_GETOPT_LONG > applet_long_options = udhcpc_longopts; > #endif > - opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vS", > + opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:A:t:vS", > &str_c, &str_V, &str_h, &str_h, &str_F, > &client_config.interface, &client_config.pidfile, &str_r, > - &client_config.script, &str_T, &str_t > + &client_config.script, &str_T, &str_A, &str_t > ); > > if (opt & OPT_c) > @@ -259,6 +262,8 @@ > client_config.timeout = xatoi_u(str_T); > if (opt & OPT_t) > client_config.retries = xatoi_u(str_t); > + if (opt & OPT_A) > + client_config.tryagain = xatoi_u(str_A); > if (opt & OPT_v) { > puts("version "BB_VER); > return 0; > @@ -355,7 +360,7 @@ > } > /* wait to try again */ > packet_num = 0; > - timeout = now + 60; > + timeout = now + client_config.tryagain; > } > break; > case RENEW_REQUESTED: > Index: networking/udhcp/dhcpc.h > =================================================================== > RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 dhcpc.h > --- networking/udhcp/dhcpc.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 > +++ networking/udhcp/dhcpc.h 5 Nov 2007 17:13:59 -0000 > @@ -30,6 +30,7 @@ > int ifindex; /* Index number of the interface to use */ > int retries; /* Max number of request packets */ > int timeout; /* Number of seconds to try to get a lease */ > + int tryagain; /* Seconds to wait after failure */ > uint8_t arp[6]; /* Our arp address */ > }; > > Index: include/usage.h > =================================================================== > RCS file: /cvs/thirdparty/busybox-1.8.0/include/usage.h,v > retrieving revision 1.1.1.1 > diff -u -r1.1.1.1 usage.h > --- include/usage.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 > +++ include/usage.h 5 Nov 2007 17:13:59 -0000 > @@ -3835,6 +3835,8 @@ > "\n -r,--request=IP IP address to request" \ > "\n -s,--script=file Run file at dhcp events (default: /usr/share/udhcpc/default.script)" \ > "\n -t,--retries=N Send up to N request packets"\ > + "\n -T,--timeout=N Try to get a lease for N seconds (default: 3)"\ > + "\n -A,--tryagain=N Wait N seconds (default: 60) after failure"\ > "\n -f,--foreground Run in foreground" \ > "\n -b,--background Background if lease cannot be immediately negotiated" \ > "\n -S,--syslog Log to syslog too" \ > > > > =--------------------- > paul fox, pgf at brightstareng.com > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Tue Nov 6 09:32:57 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 06 Nov 2007 12:32:57 -0500 Subject: [ CORRECTED ] udhcpc retry interval In-Reply-To: pgf's message of Tue, 06 Nov 2007 12:04:28 -0500. <8092.1194368668@brightstareng.com> Message-ID: <13448.1194370377@brightstareng.com> i wrote: > > when udhcpc fails to get a lease, it waits a full minute before > > trying again. in some cases this is far too long. clearly > > the udhcpc commandline is becoming over-burdened, but without > > a config file, there's not much choice: i'd like to add > > an option (i chose '-A', for "again") which lets one set the > > try-again value. here's the fixed/tested patch. i will apply in a day or two if no one objects. paul Index: networking/udhcp/dhcpc.c =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 dhcpc.c --- networking/udhcp/dhcpc.c 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ networking/udhcp/dhcpc.c 6 Nov 2007 17:29:43 -0000 @@ -144,7 +144,7 @@ int udhcpc_main(int argc, char **argv) { uint8_t *temp, *message; - char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_t; + char *str_c, *str_V, *str_h, *str_F, *str_r, *str_T, *str_A, *str_t; uint32_t xid = 0; uint32_t lease = 0; /* can be given as 32-bit quantity */ unsigned t1 = 0, t2 = 0; /* what a wonderful names */ @@ -179,6 +179,7 @@ OPT_t = 1 << 16, OPT_v = 1 << 17, OPT_S = 1 << 18, + OPT_A = 1 << 19, }; #if ENABLE_GETOPT_LONG static const char udhcpc_longopts[] ALIGN1 = @@ -200,6 +201,7 @@ "timeout\0" Required_argument "T" "version\0" No_argument "v" "retries\0" Required_argument "t" + "tryagain\0" Required_argument "A" "syslog\0" No_argument "S" ; #endif @@ -208,6 +210,7 @@ client_config.script = DEFAULT_SCRIPT; client_config.retries = 3; client_config.timeout = 3; + client_config.tryagain = 60; /* Parse command line */ opt_complementary = "c--C:C--c" // mutually exclusive @@ -215,10 +218,10 @@ #if ENABLE_GETOPT_LONG applet_long_options = udhcpc_longopts; #endif - opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vS", + opt = getopt32(argv, "c:CV:fbH:h:F:i:np:qRr:s:T:t:vSA:", &str_c, &str_V, &str_h, &str_h, &str_F, &client_config.interface, &client_config.pidfile, &str_r, - &client_config.script, &str_T, &str_t + &client_config.script, &str_T, &str_t, &str_A ); if (opt & OPT_c) @@ -259,6 +262,8 @@ client_config.timeout = xatoi_u(str_T); if (opt & OPT_t) client_config.retries = xatoi_u(str_t); + if (opt & OPT_A) + client_config.tryagain = xatoi_u(str_A); if (opt & OPT_v) { puts("version "BB_VER); return 0; @@ -355,7 +360,7 @@ } /* wait to try again */ packet_num = 0; - timeout = now + 60; + timeout = now + client_config.tryagain; } break; case RENEW_REQUESTED: Index: networking/udhcp/dhcpc.h =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/networking/udhcp/dhcpc.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 dhcpc.h --- networking/udhcp/dhcpc.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ networking/udhcp/dhcpc.h 6 Nov 2007 17:29:43 -0000 @@ -30,6 +30,7 @@ int ifindex; /* Index number of the interface to use */ int retries; /* Max number of request packets */ int timeout; /* Number of seconds to try to get a lease */ + int tryagain; /* Seconds to wait after failure */ uint8_t arp[6]; /* Our arp address */ }; Index: include/usage.h =================================================================== RCS file: /cvs/thirdparty/busybox-1.8.0/include/usage.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 usage.h --- include/usage.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 +++ include/usage.h 6 Nov 2007 17:29:43 -0000 @@ -3835,6 +3835,8 @@ "\n -r,--request=IP IP address to request" \ "\n -s,--script=file Run file at dhcp events (default: /usr/share/udhcpc/default.script)" \ "\n -t,--retries=N Send up to N request packets"\ + "\n -T,--timeout=N Try to get a lease for N seconds (default: 3)"\ + "\n -A,--tryagain=N Wait N seconds (default: 60) after failure"\ "\n -f,--foreground Run in foreground" \ "\n -b,--background Background if lease cannot be immediately negotiated" \ "\n -S,--syslog Log to syslog too" \ =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Tue Nov 6 11:30:16 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 06 Nov 2007 14:30:16 -0500 Subject: unzip headersize bug fixed Message-ID: <16188.1194377416@brightstareng.com> hi -- i commited a fix for unzip yesterday, and it occurs to me that i should probably mention it, since it's probably a candidate for 1.8.1. (the svn rev is r20369.) it turs out that at least some gcc versions (our is 3.4.1 for arm) don't fully pack structures properly -- in the case of the zip header, the elements of the structure are packed, but the end of the struct is padded from 26 out to 28 bytes. unzip was changed recently to do two things: a) verify that the structure is exactly 26 bytes, and b) use sizeof(zip_header) when reading the header. i fixed unzip.c to a) change the size check so that a struct that is only too long will pass the test, and b) changed the read back to using a constant value of 26. vda -- regarding your svn 20370/20372 -- are you sure that that warning about ATTRIBUTE_PACKED is spurious? does ATTRIBUTE_PACKED make sense on a union? i tried the same thing and backed it out because of the warning. (also -- i don't deserve credit for the telnetd zombie fix. someone else, i believe.) paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Tue Nov 6 11:55:21 2007 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 06 Nov 2007 14:55:21 -0500 Subject: /etc/passwd and symlinks Message-ID: <17121.1194378921@brightstareng.com> is there any reason that passwd and chpasswd shouldn't follow symlinks to find /etc/passwd? i have a patch to allow this, and although i've written it with a CONFIG item to protect the change, i'm wondering if the configuration option is necessary. the reason things break, currently, is that update_passwd.c creates a new copy of /etc/passwd and renames it as a final step. this renaming breaks any existing symlink. all other passwd-using utilities are perfectly happy with the link, so it's arguably just a bug that updates don't work. should i commit my patch with, or without, the config variable? (can i also hear comments on putting the Config.in change near passwd/chpasswd, rather than in libbb -- is that okay?) paul Index: libbb/update_passwd.c =================================================================== --- libbb/update_passwd.c (revision 20376) +++ libbb/update_passwd.c (working copy) @@ -52,6 +52,16 @@ int cnt = 0; int ret = -1; /* failure */ +#if ENABLE_PASSWD_FOLLOW_SYMLINKS + char resolved_filename[PATH_MAX+1]; + + if (realpath(filename, resolved_filename)) { + filename = resolved_filename; + } else { + return -1; + } +#endif + check_selinux_update_passwd(username); /* New passwd file, "/etc/passwd+" for now */ Index: loginutils/Config.in =================================================================== --- loginutils/Config.in (revision 20376) +++ loginutils/Config.in (working copy) @@ -195,6 +195,16 @@ standard input and uses this information to update a group of existing users. +config PASSWD_FOLLOW_SYMLINKS + bool "Allow passwd and chpasswd to follow symlinks to /etc/passwd" + default n + depends on PASSWD || CHPASSWD + help + Because passwd and chpasswd update a copy of /etc/passwd and then + rename the result, they will cause a symlinked /etc/passwd to + become orphaned. This change causes the symlink(s) to be + resolved before the file is updated. + config SU bool "su" default n =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Tue Nov 6 16:27:59 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 Nov 2007 00:27:59 +0000 Subject: [ CORRECTED ] udhcpc retry interval In-Reply-To: <13448.1194370377@brightstareng.com> References: <13448.1194370377@brightstareng.com> Message-ID: <200711070027.59668.vda.linux@googlemail.com> On Tuesday 06 November 2007 17:32, Paul Fox wrote: > i wrote: > > > when udhcpc fails to get a lease, it waits a full minute before > > > trying again. in some cases this is far too long. clearly > > > the udhcpc commandline is becoming over-burdened, but without > > > a config file, there's not much choice: i'd like to add > > > an option (i chose '-A', for "again") which lets one set the > > > try-again value. > > here's the fixed/tested patch. i will apply in a day or two if > no one objects. No objections. > --- include/usage.h 5 Nov 2007 13:45:42 -0000 1.1.1.1 > +++ include/usage.h 6 Nov 2007 17:29:43 -0000 > @@ -3835,6 +3835,8 @@ > "\n -r,--request=IP IP address to request" \ > "\n -s,--script=file Run file at dhcp events (default: /usr/share/udhcpc/default.script)" \ > "\n -t,--retries=N Send up to N request packets"\ > + "\n -T,--timeout=N Try to get a lease for N seconds (default: 3)"\ > + "\n -A,--tryagain=N Wait N seconds (default: 60) after failure"\ > "\n -f,--foreground Run in foreground" \ > "\n -b,--background Background if lease cannot be immediately negotiated" \ > "\n -S,--syslog Log to syslog too" \ Youforgot to add help text to the section which is active when long options are disabled. See SKIP_GETOPT_LONG(...) a few lines below that your change. -- vda From rajeevb at intoto.com Wed Nov 7 01:50:37 2007 From: rajeevb at intoto.com (Rajeev Bansal) Date: Wed, 07 Nov 2007 15:20:37 +0530 Subject: Root login from serial console Message-ID: <47318A6D.3070207@intoto.com> Hi All, I am using the busybox in my root file system, everything is fine with that, except when I try to login as a root from serial console it doesn't prompt me for the password and immediately say "Login Incorrect". I need to login as a root from serial console, so can anyone tell me how I can make it happen. I have a /etc/securetty file present and I have added the entry for ttyS0 in that. I think login utility of busybox doesn't read the securetty file. Thanks Rajeev Bansal. ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. From iali at ayesoft.com Wed Nov 7 03:41:34 2007 From: iali at ayesoft.com (Syed Irfan Ali Zaidi) Date: Wed, 7 Nov 2007 06:41:34 -0500 (EST) Subject: Tab key in busybox shell In-Reply-To: <200711061412.55427.vda.linux@googlemail.com> References: <48877.203.82.50.58.1194349145.squirrel@wm5> <200711061412.55427.vda.linux@googlemail.com> Message-ID: <57022.203.82.48.174.1194435694.squirrel@wm5> It solved my problem Thanks > On Tuesday 06 November 2007 11:39, Syed Irfan Ali Zaidi wrote: >> Hi, >> I have compiled a lattest version of busybox i-e 1.8.0. And when i >> execute >> it, it does not behave like a shell in the linux distribution. >> In linux shell, when we want to execute a command, we write the starting >> characters of the command and then use a tab key it either completes the >> command or displays the commnads thats start with the same characters. >> Then we choose from the output which command we want to use. >> But in this compiled version of busybox, when i use tab key on the >> shell, >> it does'nt do the search instead it behavious like a normal tab key that >> is it moves the cursor eight spaces ahead. Older versions of busybox had >> this feature. To enable this, are there any options for this feature? or >> Is this feature is not supported any more? What do i do? > > You need to select CONFIG_FEATURE_TAB_COMPLETION=y > and maybe CONFIG_FEATURE_USERNAME_COMPLETION=y too. > -- > vda > AyeSoft [Software Engineer] ---------------------- Clear Ur Mind Of Can't ---------------------- From jcurlnews at arcor.de Wed Nov 7 04:38:09 2007 From: jcurlnews at arcor.de (Jason Curl) Date: Wed, 7 Nov 2007 13:38:09 +0100 (CET) Subject: udhcpc general questions Message-ID: <14561185.1194439089895.JavaMail.ngmail@webmail15> Hello, I seem to be lost when understanding the power of udhcpc (and even more so when looking at the source). If I can't negotiate a lease, does udhcpc automatically support ZCIP? If not, I think I'll start udhcpc and zcip both at the same time and write scripts to get the lease or the zcip address. What do the options do? --vendorclass --clientid With reference to my previous email about obtaining a lease, I can't see how the option -R (--release) is used. I don't see my script being called with "deconfig" except on initialisation. Is this expected? Under what circumstances would my script be called with $1==nak? with $1==renew? Thanks, Jason. Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F?R ALLE NEUEINSTEIGER Jetzt bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 29,95 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From jcurlnews at arcor.de Wed Nov 7 04:29:31 2007 From: jcurlnews at arcor.de (Jason Curl) Date: Wed, 7 Nov 2007 13:29:31 +0100 (CET) Subject: udhcpc and leases Message-ID: <16312641.1194438571619.JavaMail.ngmail@webmail15> Hello, I'm looking into getting UDHCPC working again on my x86 embedded PC. If I can't get a lease, I would like to use ZCIP, otherwise use the IP that we were given. I'm using BB 1.8.0 with a very simple script to just print what it's supposed to do. I've also enabled debugging for udhcpc. When udhcpc gets a lease from the DHCP server it exits immediately. # udhcpc -s ./udhcp.script -> deconfig -> bound entering none listen mode # _ So while I haven't provided the -q option, it's still exiting after getting the lease. When reading through the source code I find: int udhcpc_main(int argc, char **argv) { ... if (opt & OPT_q) client_config.quit_after_lease = 1; ... } but I don't find where "client_config_quit_after_lease" is initialised to 0. What happens when the lease expires? How am I supposed to renegotiate a new lease? Thanks, Jason. Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F?R ALLE NEUEINSTEIGER Jetzt bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 29,95 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From pgf at brightstareng.com Wed Nov 7 05:53:22 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 07 Nov 2007 08:53:22 -0500 Subject: udhcpc general questions In-Reply-To: jcurlnews's message of Wed, 07 Nov 2007 13:38:09 +0100. <14561185.1194439089895.JavaMail.ngmail@webmail15> Message-ID: <7535.1194443602@brightstareng.com> > If I can't negotiate a lease, does udhcpc automatically > support ZCIP? no. > If not, I think I'll start udhcpc and zcip both > at the same time and write scripts to get the lease or the > zcip address. we start zcip after a dhcp lease failure. and, following the advice of someone on this list, we start zcip on an alias interface. this way when dhcp comes back, any zcip sessions can remain up. > What do the options do? > --vendorclass > --clientid these control additional DHCP option values that the client can send. "client id" normally defaults to [something very similar to] the client's mac address, and is used by the dhcp server to distinguish this client from all others. "vendor class" is a way for vendor's to extend dhcp options without having to change the RFC. see rfc 2132, search for "client identifier" and "vendor class". http://tools.ietf.org/html/rfc2132 > > With reference to my previous email about obtaining a lease, I > can't see how the option -R (--release) is used. I don't see if the udhcpc is killed (SIGTERM), then it will send a release to the server, saying "i'm done with this address". if it does this, then everyone using that address had better stop. i also notice an odd combination -- if udhcpc has been told to both "quit after obtaining a lease" and "release on quit", then as soon as it gets a lease, it will send a release, and quit. i'm not sure what use that would have, except perhaps for debugging. > my script being called with "deconfig" except on > initialisation. Is this expected? it will also be called with deconfig if, when it tries to renew the release with the server, the server never responds. in that case, the client has to start over, and so the script is run with "deconfig". calling the script with "deconfig" at init time is sort of a safety net, to be sure we're starting from a clean slate. > > Under what circumstances would my script be called with > $1==nak? the server may have been reconfigured, or maybe your client has been moved to a network where the address it is using isn't valid. in that case, when it tries to renew the address, the server will NAK the request, and the script will be so informed. > with $1==renew? when the client is in (or probably, when it enters) the "renew" state. it sounds like you'd benefit from reading a DHCP protocol overview. paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Wed Nov 7 06:03:02 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 07 Nov 2007 09:03:02 -0500 Subject: udhcpc and leases In-Reply-To: jcurlnews's message of Wed, 07 Nov 2007 13:29:31 +0100. <16312641.1194438571619.JavaMail.ngmail@webmail15> Message-ID: <8012.1194444182@brightstareng.com> > I'm looking into getting UDHCPC working again on my x86 > embedded PC. If I can't get a lease, I would like to use > ZCIP, otherwise use the IP that we were given. > > I'm using BB 1.8.0 with a very simple script to just print > what it's supposed to do. I've also enabled debugging for > udhcpc. When udhcpc gets a lease from the DHCP server it > exits immediately. are you sure it's exiting, or has it gone into the background? > > # udhcpc -s ./udhcp.script > -> deconfig > -> bound > entering none listen mode at roughly line 504 of dhcpc.c, after getting an address, the client goes into "listen none" mode, and then puts itself into the background. suppress the latter behavior with "-f". > > When reading through the source code I find: > > int udhcpc_main(int argc, char **argv) > { > ... > if (opt & OPT_q) > client_config.quit_after_lease = 1; > ... > } > > but I don't find where "client_config_quit_after_lease" is initialised to 0. client_config is an external global which is guaranteed to be zero when the applet starts. > > What happens when the lease expires? How am I supposed to > renegotiate a new lease? you would benefit from reading an overview of the dhcp protocol. your questions (though good ones) are going beyond the scope of this list, i'm afraid. (short answer: the lease won't expire if your client keeps renewing it.) paul =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Wed Nov 7 08:20:57 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 Nov 2007 16:20:57 +0000 Subject: unzip headersize bug fixed In-Reply-To: <16188.1194377416@brightstareng.com> References: <16188.1194377416@brightstareng.com> Message-ID: <200711071620.57650.vda.linux@googlemail.com> On Tuesday 06 November 2007 19:30, Paul Fox wrote: > hi -- > > i commited a fix for unzip yesterday, and it occurs to me that i > should probably mention it, since it's probably a candidate for > 1.8.1. (the svn rev is r20369.) It is there: http://busybox.net/downloads/fixes-1.8.0/busybox-1.8.0-unzip.patch > it turs out that at least some gcc versions (our is 3.4.1 for > arm) don't fully pack structures properly -- in the case of the > zip header, the elements of the structure are packed, but the end > of the struct is padded from 26 out to 28 bytes. unzip was > changed recently to do two things: a) verify that the structure > is exactly 26 bytes, and b) use sizeof(zip_header) when reading > the header. i fixed unzip.c to a) change the size check so that > a struct that is only too long will pass the test, and b) changed > the read back to using a constant value of 26. > > vda -- regarding your svn 20370/20372 -- are you sure that that warning > about ATTRIBUTE_PACKED is spurious? does ATTRIBUTE_PACKED make > sense on a union? i tried the same thing and backed it out > because of the warning. Well, I expected that PACKED there will let gcc know that entire union should be packed too. There should be a way to suppress that extra two bytes on ARM, right? Maybe PACKED will even work on ARM, I didn't check, but on i386 gcc complains. -- vda From vda.linux at googlemail.com Wed Nov 7 08:25:28 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 Nov 2007 16:25:28 +0000 Subject: udhcpc general questions In-Reply-To: <7535.1194443602@brightstareng.com> References: <7535.1194443602@brightstareng.com> Message-ID: <200711071625.28561.vda.linux@googlemail.com> On Wednesday 07 November 2007 13:53, Paul Fox wrote: > > If I can't negotiate a lease, does udhcpc automatically > > support ZCIP? > > no. > > > If not, I think I'll start udhcpc and zcip both > > at the same time and write scripts to get the lease or the > > zcip address. > > we start zcip after a dhcp lease failure. and, following the advice > of someone on this list, we start zcip on an alias interface. this > way when dhcp comes back, any zcip sessions can remain up. I hava an impression that theoretically zcip and dhcp are ortogonal. You can have both running, it's a valid network configuration. Yes you will have two addresses configured on the interface. zcip is not officially a "fallback" for dhcp, it's only used that way in Windows. -- vda From vda.linux at googlemail.com Wed Nov 7 08:51:25 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 Nov 2007 16:51:25 +0000 Subject: Root login from serial console In-Reply-To: <47318A6D.3070207@intoto.com> References: <47318A6D.3070207@intoto.com> Message-ID: <200711071651.25354.vda.linux@googlemail.com> On Wednesday 07 November 2007 09:50, Rajeev Bansal wrote: > Hi All, > > I am using the busybox in my root file system, everything is fine with Which version of busybox do you use? > that, except when I try to login as a root from serial console it > doesn't prompt me for the password and immediately say "Login > Incorrect". Do non-root logins work? Does it work if you configure busybox without CONFIG_FEATURE_SECURETTY=y? > I need to login as a root from serial console, so can > anyone tell me how I can make it happen. I have a /etc/securetty file > present and I have added the entry for ttyS0 in that. Sounds like you did everything right. > I think login > utility of busybox doesn't read the securetty file. It reads /etc/securetty here: #if ENABLE_FEATURE_SECURETTY && !ENABLE_PAM static int check_securetty(void) { FILE *fp; int i; char buf[256]; fp = fopen("/etc/securetty", "r"); if (!fp) { /* A missing securetty file is not an error. */ return 1; } while (fgets(buf, sizeof(buf)-1, fp)) { for (i = strlen(buf)-1; i >= 0; --i) { if (!isspace(buf[i])) break; } buf[++i] = '\0'; if (!buf[0] || (buf[0] == '#')) continue; if (strcmp(buf, short_tty) == 0) { fclose(fp); return 1; } } fclose(fp); return 0; } #else and checks here: pw = getpwnam(username); if (!pw) { strcpy(username, "UNKNOWN"); goto fake_it; } if (pw->pw_passwd[0] == '!' || pw->pw_passwd[0] == '*') goto auth_failed; if (opt & LOGIN_OPT_f) break; /* -f USER: success without asking passwd */ if (pw->pw_uid == 0 && !check_securetty()) <==== HERE goto auth_failed; -- vda From vda.linux at googlemail.com Wed Nov 7 08:44:13 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 Nov 2007 16:44:13 +0000 Subject: /etc/passwd and symlinks In-Reply-To: <17121.1194378921@brightstareng.com> References: <17121.1194378921@brightstareng.com> Message-ID: <200711071644.13663.vda.linux@googlemail.com> On Tuesday 06 November 2007 19:55, Paul Fox wrote: > is there any reason that passwd and chpasswd shouldn't follow > symlinks to find /etc/passwd? > > i have a patch to allow this, and although i've written it with a > CONFIG item to protect the change, i'm wondering if the > configuration option is necessary. the reason things break, > currently, is that update_passwd.c creates a new copy of > /etc/passwd and renames it as a final step. this renaming breaks > any existing symlink. all other passwd-using utilities are > perfectly happy with the link, so it's arguably just a bug that > updates don't work. I'd say having a symlinked /etc/passwd means that you probably try to live with RO /etc. You can probably achieve it in embedded setup, but on desktop it's just too hard. (Yes I did it). It's far easier to just make entire /etc writable. Having said that, I certainly don't want our passwd be an (yet another) obstacle for those who try to have RO /etc. This should be fixed. > should i commit my patch with, or without, the config variable? I think it doesn't need to be configurable. > (can i also hear comments on putting the Config.in change near > passwd/chpasswd, rather than in libbb -- is that okay?) I don't like realpath for two reasons: * it requires PATH_MAX size buffer (which is BIG). * it eats tons of stack internally: make stksizes hall of shame (uclibc static build): 0x080de75d realpath [busybox_unstripped]: 12296 <=== !!?! 0x080c4d35 input_tab [busybox_unstripped]: 10428 0x080d9013 __GI_clntudp_create [busybox_unstripped]: 9016 0x0809851b umount_main [busybox_unstripped]: 8252 0x0806bae0 rtnl_talk [busybox_unstripped]: 8240 0x0806bd7f xrtnl_dump_filter [busybox_unstripped]: 8240 0x08099996 sendMTFValues [busybox_unstripped]: 5316 0x0809a28e mainSort [busybox_unstripped]: 4700 0x08095a72 mkfs_minix_main [busybox_unstripped]: 4288 It will be great if we can avoid using it. OTOH, xmalloc_readlink has a problem that * it fails if the file is not a link, * it does not fully resolve a link to a link (to a link). > +#if ENABLE_PASSWD_FOLLOW_SYMLINKS > + char resolved_filename[PATH_MAX+1]; > + > + if (realpath(filename, resolved_filename)) { Thus I propose introducing xmalloc_readlink_recursive() which does not suffer from those two problems, and using it here (and elsewhere: insmod, syslogd - grep for xmalloc_readlink). > + filename = resolved_filename; > + } else { > + return -1; > + } > +#endif > + -- vda From pgf at brightstareng.com Wed Nov 7 08:52:34 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 07 Nov 2007 11:52:34 -0500 Subject: /etc/passwd and symlinks In-Reply-To: vda.linux's message of Wed, 07 Nov 2007 16:44:13 +0000. <200711071644.13663.vda.linux@googlemail.com> Message-ID: <12544.1194454354@brightstareng.com> > On Tuesday 06 November 2007 19:55, Paul Fox wrote: > > is there any reason that passwd and chpasswd shouldn't follow > > symlinks to find /etc/passwd? > > > > i have a patch to allow this, and although i've written it with a > > CONFIG item to protect the change, i'm wondering if the > > configuration option is necessary. the reason things break, > > currently, is that update_passwd.c creates a new copy of > > /etc/passwd and renames it as a final step. this renaming breaks > > any existing symlink. all other passwd-using utilities are > > perfectly happy with the link, so it's arguably just a bug that > > updates don't work. > > I'd say having a symlinked /etc/passwd means that you probably > try to live with RO /etc. or, in our case, a ram-disk /etc. at boot time we make copies of important configurable files in a non-volatile filesys (if there aren't already copies there from a previous boot), and replace the originals with symlinks. but it amounts to the same issue. > > should i commit my patch with, or without, the config variable? > > I think it doesn't need to be configurable. > > > (can i also hear comments on putting the Config.in change near > > passwd/chpasswd, rather than in libbb -- is that okay?) > > I don't like realpath for two reasons: > * it requires PATH_MAX size buffer (which is BIG). > * it eats tons of stack internally: > > make stksizes hall of shame (uclibc static build): > 0x080de75d realpath [busybox_unstripped]: 12296 <=== !!?! wow. :-) > Thus I propose introducing xmalloc_readlink_recursive() > which does not suffer from those two problems, > and using it here (and elsewhere: insmod, syslogd - > grep for xmalloc_readlink). okay, will do. thanks for the review. paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Wed Nov 7 13:08:17 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 07 Nov 2007 16:08:17 -0500 Subject: /etc/passwd and symlinks In-Reply-To: vda.linux's message of Wed, 07 Nov 2007 16:44:13 +0000. <200711071644.13663.vda.linux@googlemail.com> Message-ID: <6123.1194469697@brightstareng.com> denys wrote: > > Thus I propose introducing xmalloc_readlink_recursive() > which does not suffer from those two problems, > and using it here (and elsewhere: insmod, syslogd - > grep for xmalloc_readlink). well, i've written a new version, but it doesn't do what you thought it was going to. :-) realpath() fully canonicalizes a path -- it makes it absolute, removes "/..", and expands symlinks all along the path. readlink() (and also xmalloc_readlink()) simply returns the value of the named symlink. (which makes the switch from realpath() to xmalloc_readlink() somewhat suspicious, by the way.) i've written xmalloc_readlink_follow(char *path) which iteratively does textual expansion of path, expanding symlinks at the tail end of path. no other canonicalization is done, and the result is not necessarily absolute. this is the minimum needed for my "allow /etc/passwd to be a symlink" change, and it's probably useful for most of the other current uses of xmalloc_readlink(). paul /* * this routine is not the same as realpath(), which canonicalizes * the given path completely. this routine only follows trailing * symlinks until a real file is reached, and returns its name. * intermediate symlinks are not expanded. as above, a malloced * char* is returned, which must be freed. */ char *xmalloc_readlink_follow(const char *path) { char *buf = NULL, *lpc, *linkpath; int bufsize; smallint looping = 0; buf = strdup(path); bufsize = strlen(path) + 1; while(1) { linkpath = xmalloc_readlink(buf); if (!linkpath) { if (errno == EINVAL) /* not a symlink */ return buf; free(buf); return NULL; } if (*linkpath == '/') { free(buf); buf = linkpath; bufsize = strlen(linkpath) + 1; } else { bufsize += strlen(linkpath); if (looping++ > MAXSYMLINKS) { free(linkpath); free(buf); return NULL; } buf = xrealloc(buf, bufsize); lpc = bb_get_last_path_component_strip(buf); strcpy(lpc, linkpath); free(linkpath); } } } =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Wed Nov 7 16:46:33 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 Nov 2007 00:46:33 +0000 Subject: /etc/passwd and symlinks In-Reply-To: <6123.1194469697@brightstareng.com> References: <6123.1194469697@brightstareng.com> Message-ID: <200711080046.33336.vda.linux@googlemail.com> On Wednesday 07 November 2007 21:08, Paul Fox wrote: > denys wrote: > > > > Thus I propose introducing xmalloc_readlink_recursive() > > which does not suffer from those two problems, > > and using it here (and elsewhere: insmod, syslogd - > > grep for xmalloc_readlink). > > well, i've written a new version, but it doesn't do what you > thought it was going to. :-) > > realpath() fully canonicalizes a path -- it makes it absolute, > removes "/..", and expands symlinks all along the path. > > readlink() (and also xmalloc_readlink()) simply returns the value > of the named symlink. I did understand this difference. > (which makes the switch from realpath() > to xmalloc_readlink() somewhat suspicious, by the way.) ? > i've written xmalloc_readlink_follow(char *path) which iteratively > does textual expansion of path, expanding symlinks at the tail end > of path. no other canonicalization is done, and the result is not > necessarily absolute. this is the minimum needed for my "allow > /etc/passwd to be a symlink" change, and it's probably useful for > most of the other current uses of xmalloc_readlink(). Yes. Feel free to fix syslogd's use of xmalloc_readlink() too (currently it will break if /dev/log is a link to link). -- vda From pgf at brightstareng.com Wed Nov 7 17:02:30 2007 From: pgf at brightstareng.com (Paul Fox) Date: Wed, 07 Nov 2007 20:02:30 -0500 Subject: /etc/passwd and symlinks In-Reply-To: vda.linux's message of Thu, 08 Nov 2007 00:46:33 +0000. <200711080046.33336.vda.linux@googlemail.com> Message-ID: <11282.1194483750@brightstareng.com> > > > > readlink() (and also xmalloc_readlink()) simply returns the value > > of the named symlink. > > I did understand this difference. > > > (which makes the switch from realpath() > > to xmalloc_readlink() somewhat suspicious, by the way.) > > ? sorry - i left out a word: it makes the switch from realpath() to xmalloc_readlink() in insmod.c somewhat suspicious, because the variable being assigned to is "absolute_filename". i didn't look closely to see if it mattered. > > > i've written xmalloc_readlink_follow(char *path) which iteratively > > does textual expansion of path, expanding symlinks at the tail end > > of path. no other canonicalization is done, and the result is not > > necessarily absolute. this is the minimum needed for my "allow > > /etc/passwd to be a symlink" change, and it's probably useful for > > most of the other current uses of xmalloc_readlink(). > > Yes. Feel free to fix syslogd's use of xmalloc_readlink() too > (currently it will break if /dev/log is a link to link). okay. i'll commit my current changes, and then propose a separate patch to the list in case someone recognizes a case where full symlink expansion isn't right (unlikely, i suppose). paul =--------------------- paul fox, pgf at brightstareng.com From rajeevb at intoto.com Wed Nov 7 21:21:54 2007 From: rajeevb at intoto.com (Rajeev Bansal) Date: Thu, 08 Nov 2007 10:51:54 +0530 Subject: Root login from serial console In-Reply-To: <200711071651.25354.vda.linux@googlemail.com> References: <47318A6D.3070207@intoto.com> <200711071651.25354.vda.linux@googlemail.com> Message-ID: <47329CF2.5060106@intoto.com> Thanks Denys. I could fix the problem, actually there was no /etc/shadow file in my root file system and in the /etc/passwd file, the root user entry was: root:x:0:0:root:/root:/bin/ash Since shadow file was missing so somehow login utility was never probing me for the password. To solve this I created the /etc/shadow file and reset the root password and it worked for me. Thanks a lot. Rajeev Bansal. Denys Vlasenko wrote: > On Wednesday 07 November 2007 09:50, Rajeev Bansal wrote: > >> Hi All, >> >> I am using the busybox in my root file system, everything is fine with >> > > Which version of busybox do you use? > > >> that, except when I try to login as a root from serial console it >> doesn't prompt me for the password and immediately say "Login >> Incorrect". >> > > Do non-root logins work? Does it work if you configure > busybox without CONFIG_FEATURE_SECURETTY=y? > > >> I need to login as a root from serial console, so can >> anyone tell me how I can make it happen. I have a /etc/securetty file >> present and I have added the entry for ttyS0 in that. >> > > Sounds like you did everything right. > > >> I think login >> utility of busybox doesn't read the securetty file. >> > > It reads /etc/securetty here: > > #if ENABLE_FEATURE_SECURETTY && !ENABLE_PAM > static int check_securetty(void) > { > FILE *fp; > int i; > char buf[256]; > > fp = fopen("/etc/securetty", "r"); > if (!fp) { > /* A missing securetty file is not an error. */ > return 1; > } > while (fgets(buf, sizeof(buf)-1, fp)) { > for (i = strlen(buf)-1; i >= 0; --i) { > if (!isspace(buf[i])) > break; > } > buf[++i] = '\0'; > if (!buf[0] || (buf[0] == '#')) > continue; > if (strcmp(buf, short_tty) == 0) { > fclose(fp); > return 1; > } > } > fclose(fp); > return 0; > } > #else > > > and checks here: > > pw = getpwnam(username); > if (!pw) { > strcpy(username, "UNKNOWN"); > goto fake_it; > } > > if (pw->pw_passwd[0] == '!' || pw->pw_passwd[0] == '*') > goto auth_failed; > > if (opt & LOGIN_OPT_f) > break; /* -f USER: success without asking passwd */ > > if (pw->pw_uid == 0 && !check_securetty()) <==== HERE > goto auth_failed; > > -- > vda > > > ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. From Ralf.Friedl at online.de Thu Nov 8 02:52:12 2007 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Thu, 08 Nov 2007 11:52:12 +0100 Subject: /etc/passwd and symlinks In-Reply-To: <6123.1194469697@brightstareng.com> References: <6123.1194469697@brightstareng.com> Message-ID: <4732EA5C.5000002@online.de> Paul Fox wrote: > denys wrote: > > > > Thus I propose introducing xmalloc_readlink_recursive() > > which does not suffer from those two problems, > > and using it here (and elsewhere: insmod, syslogd - > > grep for xmalloc_readlink). > > well, i've written a new version, but it doesn't do what you > thought it was going to. :-) > > realpath() fully canonicalizes a path -- it makes it absolute, > removes "/..", and expands symlinks all along the path. > > readlink() (and also xmalloc_readlink()) simply returns the value > of the named symlink. (which makes the switch from realpath() > to xmalloc_readlink() somewhat suspicious, by the way.) > I think that should be no problem. The path will eventually point to a real file, and as long as the new temporary file is created in the same directory, it should be possible to rename it later. Also, I don't see why insmod should need the realpath of the object. I thought the basename of the object file is used as the module name, but I have also seen few cases where the module name was not the file name, so that seems to be only a convention and not mandatory. > i've written xmalloc_readlink_follow(char *path) which iteratively > does textual expansion of path, expanding symlinks at the tail end > of path. no other canonicalization is done, and the result is not > necessarily absolute. this is the minimum needed for my "allow > /etc/passwd to be a symlink" change, and it's probably useful for > most of the other current uses of xmalloc_readlink(). > I noticed that you test against MAXSYMLINKS only in the case of relative symlinks. I consider this inconsistent. In the case of /etc/passwd, the administrator probably can be trusted to not create a loop. But suppose you have an absolute symlink /etc/passwd -> /etc/passwd. The function would loop forever, while a stat on /etc/passwd would fail.with ELOOP. With a relative symlink /etc/passwd -> passwd the loop would be detected. Another question is what the function should do if the target of the link does not exist. xmalloc_readlink will always return the target name, whether it exists or not. I don't know whether this behavior would be useful for xmalloc_readlink_follow or not. Regards Ralf Friedl > /* > * this routine is not the same as realpath(), which canonicalizes > * the given path completely. this routine only follows trailing > * symlinks until a real file is reached, and returns its name. > * intermediate symlinks are not expanded. as above, a malloced > * char* is returned, which must be freed. > */ > char *xmalloc_readlink_follow(const char *path) > { > char *buf = NULL, *lpc, *linkpath; > int bufsize; > smallint looping = 0; > > buf = strdup(path); > bufsize = strlen(path) + 1; > > while(1) { > linkpath = xmalloc_readlink(buf); > if (!linkpath) { > if (errno == EINVAL) /* not a symlink */ > return buf; > free(buf); > return NULL; > } > > if (*linkpath == '/') { > free(buf); > buf = linkpath; > bufsize = strlen(linkpath) + 1; > } else { > bufsize += strlen(linkpath); > if (looping++ > MAXSYMLINKS) { > free(linkpath); > free(buf); > return NULL; > } > buf = xrealloc(buf, bufsize); > lpc = bb_get_last_path_component_strip(buf); > strcpy(lpc, linkpath); > free(linkpath); > } > } > } From vda.linux at googlemail.com Thu Nov 8 04:06:49 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 Nov 2007 12:06:49 +0000 Subject: /etc/passwd and symlinks In-Reply-To: <4732EA5C.5000002@online.de> References: <6123.1194469697@brightstareng.com> <4732EA5C.5000002@online.de> Message-ID: <200711081206.50069.vda.linux@googlemail.com> On Thursday 08 November 2007 10:52, Ralf Friedl wrote: > Another question is what the function should do if the target of the > link does not exist. xmalloc_readlink will always return the target > name, whether it exists or not. I don't know whether this behavior would > be useful for xmalloc_readlink_follow or not. I can imagine that people may want to call creat() on a name which is potentially a dangling link. This creates link target, if possible (it may not be: link -> /not_existing_dir/foo). Returning NULL for dangling links would make it impossible. -- vda From alexander.griesser at lkh-vil.or.at Thu Nov 8 04:48:17 2007 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Thu, 08 Nov 2007 13:48:17 +0100 Subject: /etc/passwd and symlinks In-Reply-To: <17121.1194378921@brightstareng.com> References: <17121.1194378921@brightstareng.com> Message-ID: <47330591.8020306@lkh-vil.or.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Fox wrote: > is there any reason that passwd and chpasswd shouldn't follow > symlinks to find /etc/passwd? Good question! I'm struggling with this issue for a few weeks now and always wanted to file a "bug report" on this one ;) Looking forward to see something like this implemented in a future release. Alex, trying to live with a ro /etc. - -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMwWR66HVD6KUm1oRAgNXAJ47Fx9ub9nu69whH1MW9RyPtFqoKACghEnE 1KL8oFRr97j7S0FVq/CUQQQ= =zSKe -----END PGP SIGNATURE----- From pgf at brightstareng.com Thu Nov 8 06:41:32 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 08 Nov 2007 09:41:32 -0500 Subject: /etc/passwd and symlinks In-Reply-To: Ralf.Friedl's message of Thu, 08 Nov 2007 11:52:12 +0100. <4732EA5C.5000002@online.de> Message-ID: <24359.1194532892@brightstareng.com> ralf wrote: > > Also, I don't see why insmod should need the realpath of the object. I > thought the basename of the object file is used as the module name, but > I have also seen few cases where the module name was not the file name, > so that seems to be only a convention and not mandatory. so you're saying the current code in insmod.c, and even a change to use the _follow() version of readlink, would be okay, right? just making sure i understand you. :-) > I noticed that you test against MAXSYMLINKS only in the case of relative > symlinks. I consider this inconsistent. oops, you're right. that's an oversight, which i'll fix. (note that the test isn't really guaranteed -- there may be more undetected symlinks embedded in the middle of the path, since i'm only checking the tail. but it will be caught eventually.) > > Another question is what the function should do if the target of the > link does not exist. xmalloc_readlink will always return the target > name, whether it exists or not. I don't know whether this behavior would > be useful for xmalloc_readlink_follow or not. they should probably be consistent. i can't picture a case where it wouldn't be okay to return a dangling linkname. i'll fix this too. thanks for your comments. paul =--------------------- paul fox, pgf at brightstareng.com From pgf at brightstareng.com Thu Nov 8 08:11:03 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 08 Nov 2007 11:11:03 -0500 Subject: /etc/passwd and symlinks In-Reply-To: pgf's message of Thu, 08 Nov 2007 09:41:32 -0500. <24359.1194532892@brightstareng.com> Message-ID: <31356.1194538263@brightstareng.com> i wrote: > ralf wrote: > > Another question is what the function should do if the target of the > > link does not exist. xmalloc_readlink will always return the target > > name, whether it exists or not. I don't know whether this behavior would > > be useful for xmalloc_readlink_follow or not. > > they should probably be consistent. i can't picture a case where it > wouldn't be okay to return a dangling linkname. i'll fix this too. the new version is below. there are two more behaviors that that we should be sure we agree on. these are, what to do if the pathname doesn't exist, and what to do if it's a real file. here are some test results, using the new code shown below: $ ls -l tmp total 1 lrwxrwxrwx 1 pgf users 7 Nov 8 11:03 dangling -> no-file -rw-rw-r-- 1 pgf users 0 Nov 8 11:03 existingfile lrwxrwxrwx 1 pgf users 6 Nov 8 11:02 foobar -> foobar $ ./busybox testreadlink tmp/dangling xmalloc_readlink returns no-file xmalloc_readlink_follow returns tmp/no-file $ ./busybox testreadlink tmp/existingfile xmalloc_readlink returns (null) xmalloc_readlink_follow returns tmp/existingfile $ ./busybox testreadlink tmp/foobar xmalloc_readlink returns foobar xmalloc_readlink_follow returns (null) $ ./busybox testreadlink tmp/non-existingfile xmalloc_readlink returns (null) xmalloc_readlink_follow returns tmp/non-existingfile this seems like the right behavior to me. however, the semantics are different enough between the two that maybe the new routine should have a different name. xmalloc_follow_symlinks(), perhaps. paul /* * this routine is not the same as realpath(), which * canonicalizes the given path completely. this routine only * follows trailing symlinks until a real file is reached, and * returns its name. if the path ends in a dangling link, or if * the target doesn't exist, the path is returned in any case. * intermediate symlinks in the path are not expanded -- only * those at the tail. * a malloced char* is returned, which must be freed by the caller. */ char *xmalloc_follow_symlinks(const char *path) { char *buf = NULL, *lpc, *linkpath; int bufsize; smallint looping = 0; buf = strdup(path); bufsize = strlen(path) + 1; while(1) { linkpath = xmalloc_readlink(buf); if (!linkpath) { if (errno == EINVAL || errno == ENOENT) return buf; free(buf); return NULL; } if (looping++ > MAXSYMLINKS) { free(linkpath); free(buf); return NULL; } if (*linkpath == '/') { free(buf); bufsize = strlen(linkpath) + 1; buf = linkpath; } else { bufsize += strlen(linkpath); buf = xrealloc(buf, bufsize); lpc = bb_get_last_path_component_strip(buf); strcpy(lpc, linkpath); free(linkpath); } } } =--------------------- paul fox, pgf at brightstareng.com From Ralf.Friedl at online.de Thu Nov 8 08:32:04 2007 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Thu, 08 Nov 2007 17:32:04 +0100 Subject: /etc/passwd and symlinks In-Reply-To: <24359.1194532892@brightstareng.com> References: <24359.1194532892@brightstareng.com> Message-ID: <47333A04.8070408@online.de> Paul Fox wrote: > ralf wrote: > > > > Also, I don't see why insmod should need the realpath of the object. I > > thought the basename of the object file is used as the module name, but > > I have also seen few cases where the module name was not the file name, > > so that seems to be only a convention and not mandatory. > > so you're saying the current code in insmod.c, and even a change to > use the _follow() version of readlink, would be okay, right? just making > sure i understand you. :-) > No, I didn't at all look at the insmod code. Actually this seems to refer to the code for 2.4 kernels, and I haven't used 2.4 kernels for some time. As realpath was used in add_ksymoops_symbols, I suppose ksymoops might also work with the unmodified filename, as the kernel would follow the same symlinks and eventually arrive at the same file. But I don't know and I don't have a kernel 2.4 or the utilities for the older kernels to try it. > > I noticed that you test against MAXSYMLINKS only in the case of relative > > symlinks. I consider this inconsistent. > > oops, you're right. that's an oversight, which i'll fix. (note > that the test isn't really guaranteed -- there may be more > undetected symlinks embedded in the middle of the path, since i'm > only checking the tail. but it will be caught eventually.) > symlinks in the path may cause ELOOP in readlink. That should be no problem, the final path would case ELOOP anyway. Regards Ralf Friedl From supinlick at yahoo.com Thu Nov 8 08:37:28 2007 From: supinlick at yahoo.com (Sean Parker) Date: Thu, 8 Nov 2007 08:37:28 -0800 (PST) Subject: adding GNU chkconfig Message-ID: <58024.57000.qm@web51906.mail.re2.yahoo.com> Hello - I'm using PMC-Sierra's MIPS/Linux development board (MSP8510, 'Sequoia') which uses buildroot + busybox, and I'd like to add the chkconfig binary to the image, like RH9+ has (I suppose most consumer-level Linux distirbutions have.) But I've encountered all kinds of nasty build problems trying to integrate the chkconfig package into the buildroot/busybox configuration. 1) Does busybox come with chkconfig, or a chkconfig-like tool? [it doesn't seem to] 2) chkconfig depends on popt and gettext. Busybox seems to have popt, but is it intended to have gettext also? 3) Is there a prefered method of determining how to resolve dependencies between packages I'd like to include, and the sub-set of functionality provided by busybox? Any clues would be much appreciated. Cheers Sean God Bless Sean Parker __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From vda.linux at googlemail.com Thu Nov 8 10:30:47 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 Nov 2007 11:30:47 -0700 Subject: /etc/passwd and symlinks In-Reply-To: <31356.1194538263@brightstareng.com> References: <31356.1194538263@brightstareng.com> Message-ID: <200711081130.48000.vda.linux@googlemail.com> On Thursday 08 November 2007 09:11, Paul Fox wrote: > $ ls -l tmp > total 1 > lrwxrwxrwx 1 pgf users 7 Nov 8 11:03 dangling -> no-file > -rw-rw-r-- 1 pgf users 0 Nov 8 11:03 existingfile > lrwxrwxrwx 1 pgf users 6 Nov 8 11:02 foobar -> foobar > > $ ./busybox testreadlink tmp/dangling > xmalloc_readlink returns no-file > xmalloc_readlink_follow returns tmp/no-file > > $ ./busybox testreadlink tmp/existingfile > xmalloc_readlink returns (null) > xmalloc_readlink_follow returns tmp/existingfile > > $ ./busybox testreadlink tmp/foobar > xmalloc_readlink returns foobar > xmalloc_readlink_follow returns (null) > > $ ./busybox testreadlink tmp/non-existingfile > xmalloc_readlink returns (null) > xmalloc_readlink_follow returns tmp/non-existingfile > > > this seems like the right behavior to me. to me too. > /* > * this routine is not the same as realpath(), which > * canonicalizes the given path completely. this routine only > * follows trailing symlinks until a real file is reached, and > * returns its name. if the path ends in a dangling link, or if > * the target doesn't exist, the path is returned in any case. > * intermediate symlinks in the path are not expanded -- only > * those at the tail. > * a malloced char* is returned, which must be freed by the caller. > */ > char *xmalloc_follow_symlinks(const char *path) I thought you are done and edited it in svn already, sorry. I didn't want to collide. > { > char *buf = NULL, *lpc, *linkpath; No need to store NULL > int bufsize; > smallint looping = 0; > > buf = strdup(path); xstrdup > bufsize = strlen(path) + 1; > > while(1) { > linkpath = xmalloc_readlink(buf); > if (!linkpath) { > if (errno == EINVAL || errno == ENOENT) I see. You added ENOENT. If it is the only new addition, it seems ok to me. > return buf; > free(buf); > return NULL; > } > > if (looping++ > MAXSYMLINKS) { > free(linkpath); > free(buf); > return NULL; > } > > if (*linkpath == '/') { > free(buf); > bufsize = strlen(linkpath) + 1; > buf = linkpath; > } else { > bufsize += strlen(linkpath); > buf = xrealloc(buf, bufsize); > lpc = bb_get_last_path_component_strip(buf); > strcpy(lpc, linkpath); > free(linkpath); > } > } > > } Thanks -- vda From pgf at brightstareng.com Thu Nov 8 11:58:45 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 08 Nov 2007 14:58:45 -0500 Subject: /etc/passwd and symlinks In-Reply-To: vda.linux's message of Thu, 08 Nov 2007 11:30:47 -0700. <200711081130.48000.vda.linux@googlemail.com> Message-ID: <17527.1194551925@brightstareng.com> > > I thought you are done and edited it in svn already, sorry. > I didn't want to collide. even if i wasn't, i'm always happy to fix my own bugs. on the other hand, i _never_ would have introduced that awful goto, so maybe it was better you took a crack at it. :-) ugh. i honestly feel that code like that is silly, but i understand the desire. i've made one more commit, which includes a rename of the routine. i'm done with that routine. i'll follow with another commit to change various callers to use it. paul =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Thu Nov 8 12:09:40 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 Nov 2007 13:09:40 -0700 Subject: svn commit: trunk/busybox: include libbb In-Reply-To: <20071108200037.2F823A69F5@busybox.net> References: <20071108200037.2F823A69F5@busybox.net> Message-ID: <200711081309.40616.vda.linux@googlemail.com> On Thursday 08 November 2007 13:00, pgf at busybox.net wrote: > while (1) { imagine that looping == 1 here > - if (!--looping) { > - free(linkpath); > - free(buf); > - return NULL; > - } > + > linkpath = xmalloc_readlink(buf); Say we succeed here... > if (!linkpath) { > - if (errno == EINVAL) /* not a symlink */ > + /* not a symlink, or doesn't exist */ > + if (errno == EINVAL || errno == ENOENT) > return buf; > free(buf); > return NULL; > } > - if (linkpath[0] != '/') { > + but here we reach 0 and bail out. What was the point in doing last xmalloc_readlink then? > + if (!--looping) { > + free(linkpath); > + free(buf); > + return NULL; > + } That's why I moved this check before readlink in the first place. It's mostly theoretical anyway, since MAXSYMLINKS is 20 or 30 iirc - much bigger than any reasonable case (and bigger than kernel's limit). -- vda From pgf at brightstareng.com Thu Nov 8 12:31:39 2007 From: pgf at brightstareng.com (Paul Fox) Date: Thu, 08 Nov 2007 15:31:39 -0500 Subject: svn commit: trunk/busybox: include libbb In-Reply-To: vda.linux's message of Thu, 08 Nov 2007 13:09:40 -0700. <200711081309.40616.vda.linux@googlemail.com> Message-ID: <18487.1194553899@brightstareng.com> denys wrote: > > It's mostly theoretical anyway, since MAXSYMLINKS is 20 or 30 iirc - > much bigger than any reasonable case (and bigger than kernel's limit). exactly. the loop seems misshapen enough as it is, because of the goto, that writing the rest of it in logical order seemed to make sense. =--------------------- paul fox, pgf at brightstareng.com From chris.fielder at texmemsys.com Thu Nov 8 12:41:06 2007 From: chris.fielder at texmemsys.com (Chris Fielder) Date: Thu, 08 Nov 2007 14:41:06 -0600 Subject: 'who' command formatting Message-ID: <47337462.5050407@texmemsys.com> What is the rationale behind the formatting and spacing in the 'who' command output? Specifically, the time field is too short, cutting off the last character of the seconds. At least, that's what I'm seeing. Here's what I'm seeing: user pts/0 00:00 Nov 8 09:16:1 192.168.0.1 thanks, C. Fielder From rep.dot.nop at gmail.com Thu Nov 8 13:07:06 2007 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Thu, 8 Nov 2007 22:07:06 +0100 Subject: svn commit: trunk/busybox: include libbb In-Reply-To: <20071108011142.A3E41A69E5@busybox.net> References: <20071108011142.A3E41A69E5@busybox.net> Message-ID: <20071108210706.GH6510@aon.at> On Wed, Nov 07, 2007 at 05:11:42PM -0800, pgf at busybox.net wrote: >Author: pgf >Date: 2007-11-07 17:11:41 -0800 (Wed, 07 Nov 2007) >New Revision: 20382 > >Log: >new xmalloc_readlink_follow() routine to fully expand trailing symlinks >to get to a "real" file (or directory). "Complaints" recorded as r20387. Thanks && cheers, Bernhard From ross.cameron at linuxpro.co.za Thu Nov 8 23:26:30 2007 From: ross.cameron at linuxpro.co.za (Ross Cameron) Date: Fri, 9 Nov 2007 09:26:30 +0200 Subject: adding GNU chkconfig In-Reply-To: <58024.57000.qm@web51906.mail.re2.yahoo.com> References: <58024.57000.qm@web51906.mail.re2.yahoo.com> Message-ID: <35f70db10711082326k18937dbeie484670e493c637e@mail.gmail.com> chkconfig is distribution specific to Redhat and its clones / decendants. And wont work unless you have a Redhat like init and config system. How is ure distribution constructed? On Nov 8, 2007 6:37 PM, Sean Parker wrote: > > Hello - > > I'm using PMC-Sierra's MIPS/Linux development board > (MSP8510, 'Sequoia') which uses buildroot + busybox, and > I'd like to add the chkconfig binary to the image, like > RH9+ has (I suppose most consumer-level Linux distirbutions > have.) But I've encountered all kinds of nasty build > problems trying to integrate the chkconfig package into the > buildroot/busybox configuration. > > 1) Does busybox come with chkconfig, or a chkconfig-like > tool? [it doesn't seem to] > 2) chkconfig depends on popt and gettext. Busybox seems > to have popt, but is it intended to have gettext also? > 3) Is there a prefered method of determining how to > resolve dependencies between packages I'd like to include, > and the sub-set of functionality provided by busybox? > > Any clues would be much appreciated. > > Cheers > Sean > > > > > > God Bless > Sean Parker > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > From alexander.griesser at lkh-vil.or.at Fri Nov 9 02:39:08 2007 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Fri, 09 Nov 2007 11:39:08 +0100 Subject: Different keymaps (??) on my ttys Message-ID: <473438CC.4090506@lkh-vil.or.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks! I'm experiencing a problem lateley and I don't know if it is really a busybox "bug" or just something else, but maybe someone in here can confirm this or knows how to get rid of that. When I boot my thinclient (busybox 1.7.3, BTW) I can login normally on tty1. The root password contains a '#' symbol, the keyboard layout is german. When I switch to tty2 (ALT-F2), I cannot login because the '#' symbol is interpreted as Backspace, so f.ex. entering the password "asdf#" on tty1 is "asd" on tty2, because issuing '#' deletes the 'f' as well. The really strange thing is, that I tried to use the ASCII key code trick (activate Numlock, press ALT + 035, the decimal ASCII code for '#') and it gets interpreted as Backspace too. This problem only occurs on ttys other than tty1. Maybe my de.kmap file is outdated but I don't know anymore where I got it from or how I created it. How do you load console keymaps? How can I generate the binary kmap files needed by loadkmap? Thanks in Advance, - -- Alexander Griesser (Netzwerkadministration) E-Mail: alexander.griesser at lkh-vil.or.at | Web: http://www.lkh-vil.or.at KABEG LKH Villach | Nikolaigasse 43 | 9500 Villach Tel.: +43 4242 208 3061 | Fax.: +43 4242 971 3061 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNDjM66HVD6KUm1oRApNpAJwPPzKmjYtGxYgDN6+SpfEhWPMyowCfXeMK FXrISi10jFcSQQ/CHltoVpU= =VBMx -----END PGP SIGNATURE----- From mikew at tonecommander.com Fri Nov 9 13:46:38 2007 From: mikew at tonecommander.com (Mike Wilson) Date: Fri, 9 Nov 2007 13:46:38 -0800 Subject: How do I Update FLASH Filesystem Message-ID: <001701c8231a$01d901e0$4c48a8c0@greyhawk.tonecommander.com> Hello, and thanks for reading this query. I am trying to determine the best way to upgrade software on my target. For development we can a use the command line shell of our bootloader program, but we need the unit to auto-update in the production version. Currently, we TFTP the 2 files (kernel and filesystem) to ram, and then copy the ram files to the MTDs in flash. A reboot then brings us up on the new filesystem. Apparently, the kernel and filesystem is expanded on-the-fly as needed by program operations into ram. So this is where I (think) I am running into a problem. Sometimes during the erase and programming of the MTDs, the target locks up; sometimes I get no warnings, sometimes I get "Error -3 while decompressing! 94241eda(1899)->94657000(4096)" To minimize the risk of loading code from the filesystem, I kill off the majority of the processes, although I am sure there are more I can kill. I don't think this is the answer to my problem. I am developing with a MIPS processor with MMU, Linux 2.6.10 kernel, compiled with UClibc, and BusyBox v1.2.2. My kernel is in mtd0, and mtd1 contains the filesystem, as CRAMFS. 1.) What is the "right" way to update my file system and kernel? 2.) Can I use switch_root or pivot_root to help this situation? Thank you for your expert advice. - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20071109/b6473ad8/attachment.htm From vapier at gentoo.org Fri Nov 9 20:48:08 2007 From: vapier at gentoo.org (Mike Frysinger) Date: Sat, 10 Nov 2007 00:48:08 -0400 Subject: How do I Update FLASH Filesystem In-Reply-To: <001701c8231a$01d901e0$4c48a8c0@greyhawk.tonecommander.com> References: <001701c8231a$01d901e0$4c48a8c0@greyhawk.tonecommander.com> Message-ID: <200711092348.08766.vapier@gentoo.org> On Friday 09 November 2007, Mike Wilson wrote: > Apparently, the kernel and filesystem is expanded on-the-fly as needed by > program operations into ram. So this is where I (think) I am running into a > problem. Sometimes during the erase and programming of the MTDs, the target > locks up; sometimes I get no warnings, sometimes I get > > "Error -3 while decompressing! > 94241eda(1899)->94657000(4096)" this isnt a busybox issue. please consult an embedded linux mailing list. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20071110/9cbd20b1/attachment.pgp From marc.blumentritt at arcor.de Sat Nov 10 01:54:07 2007 From: marc.blumentritt at arcor.de (Marc Blumentritt) Date: Sat, 10 Nov 2007 10:54:07 +0100 Subject: No e2fsck with bb 1.7.2 Message-ID: Hi, I use bb 1.7.2, but there is no e2fsck link created. If I run: hive devroot # bin/busybox e2fsck e2fsck: applet not found I get this. I could not find it during configuration with make menuconfig, too. Is it removed from bb or added to newer version? Regards, Marc From vda.linux at googlemail.com Sat Nov 10 22:30:36 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 10 Nov 2007 23:30:36 -0700 Subject: 'who' command formatting In-Reply-To: <47337462.5050407@texmemsys.com> References: <47337462.5050407@texmemsys.com> Message-ID: <200711102330.36985.vda.linux@googlemail.com> On Thursday 08 November 2007 13:41, Chris Fielder wrote: > What is the rationale behind the formatting and spacing in the 'who' > command output? Specifically, the time field is too short, cutting off > the last character of the seconds. At least, that's what I'm seeing. > > Here's what I'm seeing: > user pts/0 00:00 Nov 8 09:16:1 192.168.0.1 Indeed, it's a bug. Thanks for reporting. It's fixed in svn now. -- vda From vda.linux at googlemail.com Sat Nov 10 22:43:52 2007 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 10 Nov 2007 23:43:52 -0700 Subject: No e2fsck with bb 1.7.2 In-Reply-To: References: Message-ID: <200711102343.52869.vda.linux@googlemail.com> On Saturday 10 November 2007 02:54, Marc Blumentritt wrote: > Hi, > > I use bb 1.7.2, but there is no e2fsck link created. If I run: > > hive devroot # bin/busybox e2fsck > e2fsck: applet not found > > I get this. I could not find it during configuration with make > menuconfig, too. Is it removed from bb or added to newer version? It was disabled. The source is still in the tree: e2fsprogs/old_e2fsprogs/e2fsck.c It was disabled because it wasn't really 'busyboxed' (audited for bloat) when it was added to busybox. As a result, it is bigger than ash (the biggest existing applet). There are two possible courses of action: use stock e2fsprogs or work on making e2fsck which is small enough to be included in busybox. Since e2fsck is such an important utility, I think first option is much safer. -- vda From farmatito at tiscali.it Sun Nov 11 04:29:03 2007 From: farmatito at tiscali.it (Tito) Date: Sun, 11 Nov 2007 13:29:03 +0100 Subject: [PATCH] who.c minor size reduction Message-ID: <200711111329.03360.farmatito@tiscali.it> Hi, this size reduces size of who.c by removing a variable. The patch is tested and works for me. Bloat o meter says: scripts/bloat-o-meter busybox_old busybox_unstripped function old new delta who_main 279 271 -8 ------------------------------------------------------------------------------ (add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8) Total: -8 bytes BTW: a silly question, why we don't remove the check for USER_PROCESS in this line: if (ut->ut_user[0] && ut->ut_type == USER_PROCESS) so that we get the output of who -a for free and reduce size at the same time. Currently there is no way to do this. Output would be: ./busybox who USER TTY IDLE TIME HOST reboot ~ ? Nov 11 10:06:20 runlevel ~ ? Nov 11 10:06:20 LOGIN tty1 03:17 Nov 11 10:06:47 tito tty2 00:01 Nov 11 13:22:31 LOGIN tty3 03:17 Nov 11 10:06:47 LOGIN tty4 03:17 Nov 11 10:06:47 LOGIN tty5 03:17 Nov 11 10:06:47 LOGIN tty6 03:17 Nov 11 10:06:47 Just an idea..... Ciao, Tito diff -uN coreutils/who_orig.c coreutils/who.c --- coreutils/who_orig.c 2007-11-11 10:55:36.000000000 +0100 +++ coreutils/who.c 2007-11-11 13:18:53.000000000 +0100 @@ -55,7 +55,6 @@ printf("USER TTY IDLE TIME HOST\n"); while ((ut = getutent()) != NULL) { if (ut->ut_user[0] && ut->ut_type == USER_PROCESS) { - time_t thyme = ut->ut_tv.tv_sec; /* ut->ut_line is device name of tty - "/dev/" */ name = concat_path_file("/dev", ut->ut_line); @@ -66,7 +65,7 @@ /* 15 chars for time: Nov 10 19:33:20 */ printf("%-10s %-8s %-9s %-15.15s %s\n", ut->ut_user, ut->ut_li