From claus.klein at arcormail.de Tue Jan 1 13:26:31 2008 From: claus.klein at arcormail.de (Claus Klein) Date: Tue, 01 Jan 2008 22:26:31 +0100 Subject: [PATCH] to add Mark Lord's symlinks to busybox In-Reply-To: <4773927A.1080208@arcormail.de> References: <4773927A.1080208@arcormail.de> Message-ID: <477AB007.2080004@arcormail.de> Claus Klein schrieb: > Hi all, > > I prepared a symlinks applet to busybox. It > Scans directories for symbolic links, and identifies dangling, relative, > absolute, messy, lengthy and other_fs links. Can optionally change > absolute > links to relative within a given filesystem. Recommended for use by > anyone > developing and/or maintaining a Linux distribution or CD-ROM. > > Too I added a chroot option to it to be able to check the symlinks in > a target root > file system on a development host to prevent dead links on the > embedded system. > > Claus Ps: with symlink you may find bugs like this: root at slax:/buildroot/project_build_i386/uclibc/root# symlinks -r -R . chroot to /mnt/hda1/buildroot/project_build_i386/uclibc/root: cwd: / dangling: /etc/mtab -> ../proc/mounts dangling: /etc/resolv.conf -> ../tmp/resolv.conf dangling: /usr/lib/terminfo -> /mnt/hda1/buildroot/build_i386/staging_dir/usr/share/terminfo <<<<<<<<<<<<<<<< :-(( messy: /usr/bin/slogin -> ./ssh dangling: /var/lib/avahi-autoipd -> /tmp/avahi-autoipd root at slax:/buildroot/project_build_i386/uclibc/root# ck From natanael.copa at gmail.com Wed Jan 2 07:23:02 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Wed, 02 Jan 2008 16:23:02 +0100 Subject: [PATCH] coreutils tac (was: coreutils tac) In-Reply-To: <200712290829.34342.farmatito@tiscali.it> References: <1198572349.7769.2.camel@nc.nor.wtbts.org> <200712282236.27651.farmatito@tiscali.it> <200712290218.13119.vda.linux@googlemail.com> <200712290829.34342.farmatito@tiscali.it> Message-ID: <1199287382.6084.0.camel@nc.nor.wtbts.org> Denys, whats the status on the tac patch? On Sat, 2007-12-29 at 08:29 +0100, Tito wrote: > On Saturday 29 December 2007 03:18:13 Denys Vlasenko wrote: > > On Friday 28 December 2007 21:36, Tito wrote: > > > just for fun I've created an alternative version of tac > > > using only linked lists in memory. Probably the size > > > is smaller but I haven't checked it yet as I > > > would like to hear first the opinion of the list > > > members about it. For the same reason i haven't > > > attached a patch but only a drop in replacement > > > of tac.c. > > > Hints, critics, improvements and correction > > > are always welcome!!! > > > > Small :) > > > > What will happen with big files? > > -- > > vda > > > > With big files there will be an out of memory error and > the applet is not NOFORK. > There are also some bugs with embedded '\0' chars > and lines ending without '\n' > that i think i've fixed in this version. > More tests are needed with special files > as i tested only with regular files, empty files, > links, broken links and directories. > New version attached. > > > Ciao, > TIto From vda.linux at googlemail.com Wed Jan 2 07:58:44 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 2 Jan 2008 15:58:44 +0000 Subject: [patch] netstat: got bogus unix line... In-Reply-To: <0801010307250.11092@somehost> References: <0712251249090.9997@somehost> <0712300317500.11092@somehost> <0801010307250.11092@somehost> Message-ID: <200801021558.44938.vda.linux@googlemail.com> On Tuesday 01 January 2008 02:22, Cristian Ionescu-Idbohrn wrote: > On Sun, 30 Dec 2007, Cristian Ionescu-Idbohrn wrote: > > > There must be some sort of confusion/misunderstanding somewhere :( > > Let me try again. net-tools netstat shows this: > > > > unix 2 [ ACC ] STREAM LISTENING 14220 private/mailman > > unix 2 [ ] DGRAM 14954 @ > > warning, got bogus unix line. > > unix 2 [ ACC ] STREAM LISTENING 14164 private/relay > > > > and bb-netstat shows this: > > > > unix 2 [ ACC ] STREAM LISTENING 14220 private/mailman > > unix 2 [ ] DGRAM 14954 @ > > unix 2 [ ACC ] STREAM LISTENING 14164 private/relay > > With the attached patch, bb-netstat will produce these lines: > > unix 2 [ ACC ] STREAM LISTENING 14220 private/mailman > unix 2 [ ] DGRAM 14954 @ > netstat: warning, got bogus data on line 13 in /proc/net/unix > netstat: warning, got bogus data on line 14 in /proc/net/unix > unix 2 [ ACC ] STREAM LISTENING 14164 private/relay > > revealing the corruption (similar to but better than net-tools netstat ;)). > This is what I was looking for. The thread started by you reporting a bug where netstat crashed trying to print binary data to stdout. This was fixed. Now it even prints non-printable characters safely. The only remaining problems are that it does not print weird names with embedded NULs, and does not like even weirder names with '\n' in them. In the first case netstat just prints everything up to NUL (with no warning), in second case it will warn about "bogus line". You want first case to also emit a warning. You add code to detect it. I don't agree on that, since does not seem to be particularly useful, even worse: it will warn on this name: @/tmp/fam-vda-^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@...^@ which looks like a non-bogus name to me. I think current netstat behavior is good enough. -- vda From cristian.ionescu-idbohrn at axis.com Wed Jan 2 08:45:47 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Wed, 2 Jan 2008 17:45:47 +0100 (CET) Subject: [patch] netstat: got bogus unix line... In-Reply-To: <200801021558.44938.vda.linux@googlemail.com> References: <0712251249090.9997@somehost> <0712300317500.11092@somehost> <0801010307250.11092@somehost> <200801021558.44938.vda.linux@googlemail.com> Message-ID: <0801021723170.11092@somehost> On Wed, 2 Jan 2008, Denys Vlasenko wrote: > The thread started by you reporting a bug where netstat crashed trying > to print binary data to stdout. This was fixed. Yes, and I'm happy with that fix. > Now it even prints non-printable characters safely. And that's very good too. > The only remaining problems are that it does not print weird names with > embedded NULs, and does not like even weirder names with '\n' in them. Those are IMO not problems. bb-netstat should _not_ print weird names with embedded NULs or even weirder names with '\n' in them. > In the first case netstat just prints everything up to NUL (with no > warning), Right. > in second case it will warn about "bogus line". That does not happen in my case. bb-netstat does not print any "bogus line" warning when the line read from /proc/net/unix looks like this: 00000350: 6637 6162 3632 3830 f7ab6280 00000360: 3A20 3030 3030 3030 3032 2030 3030 3030 : 00000002 00000 00000370: 3030 3020 3030 3030 3030 3030 2030 3030 000 00000000 000 00000380: 3220 3031 2031 3439 3534 2040 0000 009E 2 01 14954 @.... 00000390: 1200 0078 2A0A 0000 0000 0000 0000 0000 ...x*........... 000003A0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000003B0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000003C0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000003D0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000003E0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000003F0: 0000 0000 0000 000A ........ Two embedded '\n' above. net-tools netstat warns, but I'm not sure if the warning adresses the 1st part (up to the 1st '\n') or the 2nd part which starts with NUL characters and ends with a '\n'. > You want first case to also emit a warning. You add code to detect it. Yes, because that indicates corruption. > I don't agree on that, since does not seem to be particularly useful, > even worse: it will warn on this name: > > @/tmp/fam-vda-^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@...^@ > > which looks like a non-bogus name to me. Hmm... Looks bogus to me. > I think current netstat behavior is good enough. Alright. I won't push it any further. I think we can agree that we disagree on that matter ;) Cheers, -- Cristian From mpfj at mimc.co.uk Thu Jan 3 04:15:41 2008 From: mpfj at mimc.co.uk (Mark Jackson) Date: Thu, 03 Jan 2008 12:15:41 +0000 Subject: Persistent CGI ? Message-ID: <477CD1ED.2030500@mimc.co.uk> Can anyone tell me if busybox supports PCGI ? From the docs, I'm guessing not, but I thought I'd just check. Regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080103/41e2c665/attachment.htm From yan at seiner.com Thu Jan 3 06:20:13 2008 From: yan at seiner.com (Yan Seiner) Date: Thu, 03 Jan 2008 06:20:13 -0800 Subject: Persistent CGI ? In-Reply-To: <477CD1ED.2030500@mimc.co.uk> References: <477CD1ED.2030500@mimc.co.uk> Message-ID: <477CEF1D.7040208@seiner.com> Mark Jackson wrote: > Can anyone tell me if busybox supports PCGI ? > > >From the docs, I'm guessing not, but I thought I'd just check. > > Regards > Mark Not sure what you're asking, but I think the anwer is no. busybox's http will reinitialize php (or whatever cgi backend you may be using) every time it is called. I changed to lighttpd for that very reason; it keeps php resident in memory. --Yan From martinb at zeelandnet.nl Thu Jan 3 09:33:56 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Thu, 3 Jan 2008 18:33:56 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <477CEF1D.7040208@seiner.com> Message-ID: After 6 months I did give the new busybox (1.9.0) a look and I try to compile hush on my system (arm no mmu) But sadly its giving me the exact situation it did 6 months ago http://www.busybox.net/lists/busybox/2007-June/027605.html the current hush is working much better now for scripting but I cant use is for active shell and still need to use a old lash version (1.2.0) If someone is interesting in solving this problem then I'm willing to give as much feedback possible to help on this. Some extra info. Hush did never work for active shell (i can use it for processing scripts) If i start hush from lash i get the exact same problem i did compile with all possible combination of options but all same results From vda.linux at googlemail.com Thu Jan 3 11:26:33 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 3 Jan 2008 19:26:33 +0000 Subject: [PATCH] coreutils tac (was: coreutils tac) In-Reply-To: <1199287382.6084.0.camel@nc.nor.wtbts.org> References: <1198572349.7769.2.camel@nc.nor.wtbts.org> <200712290829.34342.farmatito@tiscali.it> <1199287382.6084.0.camel@nc.nor.wtbts.org> Message-ID: <200801031926.33584.vda.linux@googlemail.com> On Wednesday 02 January 2008 15:23, Natanael Copa wrote: > Denys, whats the status on the tac patch? > > On Sat, 2007-12-29 at 08:29 +0100, Tito wrote: > > On Saturday 29 December 2007 03:18:13 Denys Vlasenko wrote: > > > On Friday 28 December 2007 21:36, Tito wrote: > > > > just for fun I've created an alternative version of tac > > > > using only linked lists in memory. Probably the size > > > > is smaller but I haven't checked it yet as I > > > > would like to hear first the opinion of the list > > > > members about it. For the same reason i haven't > > > > attached a patch but only a drop in replacement > > > > of tac.c. > > > > Hints, critics, improvements and correction > > > > are always welcome!!! > > > > > > Small :) > > > > > > What will happen with big files? > > > -- > > > vda > > > > > > > With big files there will be an out of memory error and > > the applet is not NOFORK. > > There are also some bugs with embedded '\0' chars > > and lines ending without '\n' > > that i think i've fixed in this version. > > More tests are needed with special files > > as i tested only with regular files, empty files, > > links, broken links and directories. > > New version attached. I will take a look and probably will apply it on weekend. -- vda From vda.linux at googlemail.com Thu Jan 3 11:48:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 3 Jan 2008 19:48:37 +0000 Subject: Hush cant replace lash for my situation In-Reply-To: References: Message-ID: <200801031948.37216.vda.linux@googlemail.com> On Thursday 03 January 2008 17:33, Martinb_ARM_NOMMU_KISSDVD wrote: > > After 6 months I did give the new busybox (1.9.0) a look and I try to > compile hush on my system (arm no mmu) > But sadly its giving me the exact situation it did 6 months ago > > http://www.busybox.net/lists/busybox/2007-June/027605.html > > the current hush is working much better now for scripting but I cant use is > for active shell and still need to use a old lash version (1.2.0) > If someone is interesting in solving this problem then I'm willing to give > as much feedback possible to help on this. Yes, please. That old thread drifted off-topic last time. So: does hust work for you with same .config on x86 built against glibc? Which libc do you build against? If it is uclibc, post uclibc .config. Please post busybox .config. -- vda From harald-tuxbox at arcor.de Thu Jan 3 15:58:30 2008 From: harald-tuxbox at arcor.de (=?ISO-8859-1?Q?Harald_K=FCthe?=) Date: Thu, 03 Jan 2008 23:58:30 +0000 Subject: [PATCH] zombie processes (maybe was: init does not kill reparented processes) Message-ID: <477D76A6.10408@arcor.de> Hello list, There exists a patch which is hanging around in our development tree for ages now which we used to avoid zombie processes. This is maybe related to some old stuff found here: http://www.busybox.net/lists/busybox/2004-August/012422.html Our inittab calls a startscript which is not ended during runtime, but only when the settopbox shuts down. If you are interested, here's the patch. ppc8xx/linux-2.4.35/libc-2.3.6/gcc-3.4.6. Best regards Harald diff -Naur busybox-1.9.0/init/init.c busybox-1.9.0-dbox2/init/init.c --- busybox-1.9.0/init/init.c 2007-12-21 23:00:32.000000000 +0100 +++ busybox-1.9.0-dbox2/init/init.c 2008-01-03 23:35:45.000000000 +0000 @@ -497,10 +497,12 @@ int status, wpid; while (1) { - wpid = waitpid(runpid, &status, 0); - if (wpid == -1 && errno == EINTR) + wpid = wait(&status); + if (wpid >0 && wpid != runpid) { continue; - break; + } + if (wpid == runpid) + break; } return wpid; } From vda.linux at googlemail.com Fri Jan 4 07:03:53 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jan 2008 15:03:53 +0000 Subject: [PATCH] zombie processes (maybe was: init does not kill reparented processes) In-Reply-To: <477D76A6.10408@arcor.de> References: <477D76A6.10408@arcor.de> Message-ID: <200801041503.53628.vda.linux@googlemail.com> On Thursday 03 January 2008 23:58, Harald K?the wrote: > Hello list, > There exists a patch which is hanging around in our development tree for > ages now which we used to avoid zombie processes. > This is maybe related to some old stuff found here: > http://www.busybox.net/lists/busybox/2004-August/012422.html > Our inittab calls a startscript which is not ended during runtime, but > only when the settopbox shuts down. > > If you are interested, here's the patch. > ppc8xx/linux-2.4.35/libc-2.3.6/gcc-3.4.6. > > Best regards > Harald > > diff -Naur busybox-1.9.0/init/init.c busybox-1.9.0-dbox2/init/init.c > --- busybox-1.9.0/init/init.c 2007-12-21 23:00:32.000000000 +0100 > +++ busybox-1.9.0-dbox2/init/init.c 2008-01-03 23:35:45.000000000 +0000 > @@ -497,10 +497,12 @@ > int status, wpid; > > while (1) { > - wpid = waitpid(runpid, &status, 0); > - if (wpid == -1 && errno == EINTR) > + wpid = wait(&status); > + if (wpid >0 && wpid != runpid) { > continue; > - break; > + } > + if (wpid == runpid) > + break; > } > return wpid; > } Applied, thanks! -- vda From dv at vollmann.ch Fri Jan 4 06:58:40 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Fri, 04 Jan 2008 15:58:40 +0100 Subject: [PATCH] time options for ps Message-ID: <477E49A0.77156861@vollmann.ch> Hello, the attached patch adds 'time' and 'etime' for ps. It adds more than 2k (but only for CONFIG_DESKTOP) because of the expensive computation of HZ. If we omit support for pre-2.4 Linux, the space addition would go way done. Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ -------------- next part -------------- diff -Nupr busybox-1.9.0-orig/include/libbb.h busybox-1.9.0/include/libbb.h --- busybox-1.9.0-orig/include/libbb.h Fri Dec 21 23:00:31 2007 +++ busybox-1.9.0/include/libbb.h Thu Jan 3 21:59:37 2008 @@ -982,6 +982,7 @@ typedef struct procps_status_t { * it is memset(0) for each process in procps_scan() */ unsigned long vsz, rss; /* we round it to kbytes */ unsigned long stime, utime; + unsigned long start_time; unsigned pid; unsigned ppid; unsigned pgid; @@ -1024,11 +1025,12 @@ enum { PSSCAN_SMAPS = (1 << 15) * ENABLE_FEATURE_TOPMEM, PSSCAN_ARGVN = (1 << 16) * (ENABLE_PGREP | ENABLE_PKILL), USE_SELINUX(PSSCAN_CONTEXT = 1 << 17,) + PSSCAN_START_TIME = 1 << 18, /* These are all retrieved from proc/NN/stat in one go: */ PSSCAN_STAT = PSSCAN_PPID | PSSCAN_PGID | PSSCAN_SID | PSSCAN_COMM | PSSCAN_STATE | PSSCAN_VSZ | PSSCAN_RSS - | PSSCAN_STIME | PSSCAN_UTIME + | PSSCAN_STIME | PSSCAN_UTIME | PSSCAN_START_TIME | PSSCAN_TTY, }; procps_status_t* alloc_procps_scan(int flags); @@ -1040,6 +1042,11 @@ void read_cmdline(char *buf, int col, un pid_t *find_pid_by_name(const char* procName); pid_t *pidlist_reverse(pid_t *pidList); +#if ENABLE_DESKTOP +extern unsigned long Hertz; +extern unsigned long seconds_since_boot; +void init_hertz(void); +#endif extern const char bb_uuenc_tbl_base64[]; extern const char bb_uuenc_tbl_std[]; diff -Nupr busybox-1.9.0-orig/libbb/procps.c busybox-1.9.0/libbb/procps.c --- busybox-1.9.0-orig/libbb/procps.c Fri Dec 21 23:00:29 2007 +++ busybox-1.9.0/libbb/procps.c Thu Jan 3 22:52:59 2008 @@ -243,7 +243,8 @@ procps_status_t *procps_scan(procps_stat "%lu %lu " /* utime, stime */ "%*s %*s %*s " /* cutime, cstime, priority */ "%ld " /* nice */ - "%*s %*s %*s " /* timeout, it_real_value, start_time */ + "%*s %*s " /* timeout, it_real_value */ + "%lu " /* start_time */ "%lu " /* vsize */ "%lu " /* rss */ /* "%lu %lu %lu %lu %lu %lu " rss_rlim, start_code, end_code, start_stack, kstk_esp, kstk_eip */ @@ -254,6 +255,7 @@ procps_status_t *procps_scan(procps_stat &sp->pgid, &sp->sid, &tty, &sp->utime, &sp->stime, &tasknice, + &sp->start_time, &vsz, &rss); if (n != 10) @@ -280,7 +282,8 @@ procps_status_t *procps_scan(procps_stat sp->stime = fast_strtoul_10(&cp); cp = skip_fields(cp, 3); /* cutime, cstime, priority */ tasknice = fast_strtoul_10(&cp); - cp = skip_fields(cp, 3); /* timeout, it_real_value, start_time */ + cp = skip_fields(cp, 2); /* timeout, it_real_value */ + sp->start_time = fast_strtoul_10(&cp); /* vsz is in bytes and we want kb */ sp->vsz = fast_strtoul_10(&cp) >> 10; /* vsz is in bytes but rss is in *PAGES*! Can you believe that? */ diff -Nupr busybox-1.9.0-orig/procps/Kbuild busybox-1.9.0/procps/Kbuild --- busybox-1.9.0-orig/procps/Kbuild Fri Dec 21 23:00:32 2007 +++ busybox-1.9.0/procps/Kbuild Thu Jan 3 15:58:11 2008 @@ -14,6 +14,7 @@ lib-$(CONFIG_PGREP) += pgrep.o lib-$(CONFIG_PKILL) += pgrep.o lib-$(CONFIG_PIDOF) += pidof.o lib-$(CONFIG_PS) += ps.o +lib-$(CONFIG_PS) += sysinfo.o lib-$(CONFIG_RENICE) += renice.o lib-$(CONFIG_BB_SYSCTL) += sysctl.o lib-$(CONFIG_TOP) += top.o diff -Nupr busybox-1.9.0-orig/procps/ps.c busybox-1.9.0/procps/ps.c --- busybox-1.9.0-orig/procps/ps.c Fri Dec 21 23:00:32 2007 +++ busybox-1.9.0/procps/ps.c Thu Jan 3 22:54:16 2008 @@ -73,6 +73,30 @@ static void func_tty(char *buf, int size snprintf(buf, size+1, "%u,%u", ps->tty_major, ps->tty_minor); } +static void func_etime(char *buf, int size, const procps_status_t *ps) +{ + /* elapsed time [[dd-]hh:]mm:ss; here only mm:ss */ + unsigned long mm; + unsigned ss; + + mm = seconds_since_boot - (unsigned long)(ps->start_time / Hertz); + ss = mm % 60; + mm /= 60; + snprintf(buf, size+1, "%3lu:%02u", mm, ss); +} + +static void func_time(char *buf, int size, const procps_status_t *ps) +{ + /* cumulative time [[dd-]hh:]mm:ss; here only mm:ss */ + unsigned long mm; + unsigned ss; + + mm = (ps->utime + ps->stime) / Hertz; + ss = mm % 60; + mm /= 60; + snprintf(buf, size+1, "%3lu:%02u", mm, ss); +} + #if ENABLE_SELINUX static void func_label(char *buf, int size, const procps_status_t *ps) { @@ -86,16 +110,6 @@ static void func_nice(char *buf, int siz ps->??? } -static void func_etime(char *buf, int size, const procps_status_t *ps) -{ - elapled time [[dd-]hh:]mm:ss -} - -static void func_time(char *buf, int size, const procps_status_t *ps) -{ - cumulative time [[dd-]hh:]mm:ss -} - static void func_pcpu(char *buf, int size, const procps_status_t *ps) { } @@ -117,13 +131,13 @@ static const ps_out_t out_spec[] = { { 5 , "pid" ,"PID" ,func_pid ,PSSCAN_PID }, { 5 , "ppid" ,"PPID" ,func_ppid ,PSSCAN_PPID }, { 5 , "pgid" ,"PGID" ,func_pgid ,PSSCAN_PGID }, -// { sizeof("ELAPSED")-1, "etime" ,"ELAPSED",func_etime ,PSSCAN_ }, + { sizeof("ELAPSED")-1, "etime" ,"ELAPSED",func_etime ,PSSCAN_START_TIME }, // { sizeof("GROUP" )-1, "group" ,"GROUP" ,func_group ,PSSCAN_UIDGID }, // { sizeof("NI" )-1, "nice" ,"NI" ,func_nice ,PSSCAN_ }, // { sizeof("%CPU" )-1, "pcpu" ,"%CPU" ,func_pcpu ,PSSCAN_ }, // { sizeof("RGROUP" )-1, "rgroup","RGROUP" ,func_rgroup,PSSCAN_UIDGID }, // { sizeof("RUSER" )-1, "ruser" ,"RUSER" ,func_ruser ,PSSCAN_UIDGID }, -// { sizeof("TIME" )-1, "time" ,"TIME" ,func_time ,PSSCAN_ }, + { 6 , "time" ,"TIME" ,func_time ,PSSCAN_STIME | PSSCAN_UTIME }, { 6 , "tty" ,"TT" ,func_tty ,PSSCAN_TTY }, { 4 , "vsz" ,"VSZ" ,func_vsz ,PSSCAN_VSZ }, // Not mandated by POSIX, but useful: @@ -137,7 +151,7 @@ static const ps_out_t out_spec[] = { #define SELINIX_O_PREFIX "label," #define DEFAULT_O_STR SELINIX_O_PREFIX "pid,user" /* TODO: ,vsz,stat */ ",args" #else -#define DEFAULT_O_STR "pid,user" /* TODO: ,vsz,stat */ ",args" +#define DEFAULT_O_STR "pid,user,time" /* TODO: ,vsz,stat */ ",args" #endif struct globals { @@ -317,6 +331,7 @@ int ps_main(int argc, char **argv) parse_o(default_o); } post_process(); + init_hertz(); /* Was INT_MAX, but some libc's go belly up with printf("%.*s") * and such large widths */ diff -Nupr busybox-1.9.0-orig/procps/sysinfo.c busybox-1.9.0/procps/sysinfo.c --- busybox-1.9.0-orig/procps/sysinfo.c Thu Jan 1 01:00:00 1970 +++ busybox-1.9.0/procps/sysinfo.c Fri Jan 4 15:04:46 2008 @@ -0,0 +1,247 @@ +// sysinfo.c - compute the Hertz value (HZ inside the kernel) +// taken from procps-3.2.7 +// +// adaption for busybox by Detlef Vollmann, Siemens, January 2008 +// original copyright notices: +// Copyright (C) 1992-1998 by Michael K. Johnson, johnsonm at redhat.com +// Copyright 1998-2003 Albert Cahalan +// +// This file is placed under the conditions of the GNU Library +// General Public License, version 2, or any later version. +// See file COPYING for information on distribution conditions. +// + +#if ENABLE_DESKTOP +#include "libbb.h" + +#ifndef HZ +#include /* htons */ +#endif + +#define BAD_OPEN_MESSAGE "Error: /proc must be mounted\n" + +#define STAT_FILE "/proc/stat" +#define UPTIME_FILE "/proc/uptime" + +#define PROCPS_BUF_SIZE 1024 + + +/************** this part taken from version.c of procps-3.2.7 ********* + * Linux kernel version information for procps utilities + * Copyright (c) 1996 Charles Blake + */ +#include + +#define LINUX_VERSION(x,y,z) (0x10000*(x) + 0x100*(y) + z) + +static int linux_version_code; + +static void init_Linux_version(void) +{ + static struct utsname uts; + int x = 0, y = 0, z = 0; /* cleared in case sscanf() < 3 */ + + if (uname(&uts) == -1) { /* failure implies impending death */ + exit(1); + } + if (sscanf(uts.release, "%d.%d.%d", &x, &y, &z) < 3) { + fprintf(stderr, /* *very* unlikely to happen by accident */ + "Non-standard uts for running kernel:\n" + "release %s=%d.%d.%d gives version code %d\n", + uts.release, x, y, z, LINUX_VERSION(x, y, z)); + } + linux_version_code = LINUX_VERSION(x, y, z); +} + +/*********************** end version.c part ****************************/ + +/*********************************************************************** + * Some values in /proc are expressed in units of 1/HZ seconds, where HZ + * is the kernel clock tick rate. One of these units is called a jiffy. + * The HZ value used in the kernel may vary according to hacker desire. + * According to Linus Torvalds, this is not true. He considers the values + * in /proc as being in architecture-dependant units that have no relation + * to the kernel clock tick rate. Examination of the kernel source code + * reveals that opinion as wishful thinking. + * + * In any case, we need the HZ constant as used in /proc. (the real HZ value + * may differ, but we don't care) There are several ways we could get HZ: + * + * 1. Include the kernel header file. If it changes, recompile this library. + * 2. Use the sysconf() function. When HZ changes, recompile the C library! + * 3. Ask the kernel. This is obviously correct... + * + * Linus Torvalds won't let us ask the kernel, because he thinks we should + * not know the HZ value. Oh well, we don't have to listen to him. + * Someone smuggled out the HZ value. :-) + * + * This code should work fine, even if Linus fixes the kernel to match his + * stated behavior. The code only fails in case of a partial conversion. + * + * Recent update: on some architectures, the 2.4 kernel provides an + * ELF note to indicate HZ. This may be for ARM or user-mode Linux + * support. This ought to be investigated. Note that sysconf() is still + * unreliable, because it doesn't return an error code when it is + * used with a kernel that doesn't support the ELF note. On some other + * architectures there may be a system call or sysctl() that will work. + */ + +unsigned long Hertz = 0; +unsigned long seconds_since_boot = 0; +static long smp_num_cpus = 0; + +static inline void file_to_buf(char const *filename, char *buf) +{ + if (open_read_close(filename, buf, sizeof(buf)) < 0) { + bb_error_msg_and_die(BAD_OPEN_MESSAGE); + } +} + +static void old_Hertz_hack(void) +{ + char buf[PROCPS_BUF_SIZE]; + unsigned long long user_j, nice_j, sys_j, other_j; /* jiffies (clock ticks) */ + double up_1, up_2, seconds; + unsigned long long jiffies; + unsigned h; + + if (smp_num_cpus == 0) { + smp_num_cpus = sysconf(_SC_NPROCESSORS_ONLN); + if (smp_num_cpus < 1) { + smp_num_cpus = 1; /* SPARC glibc is buggy */ + } + } +#if ENABLE_LOCALE_SUPPORT + char *restrict savelocale; + + savelocale = setlocale(LC_NUMERIC, NULL); + setlocale(LC_NUMERIC, "C"); +#endif + do { + file_to_buf(UPTIME_FILE, buf); + sscanf(buf, "%lf", &up_1); + file_to_buf(STAT_FILE, buf); + sscanf(buf, "cpu %Lu %Lu %Lu %Lu", &user_j, &nice_j, &sys_j, + &other_j); + file_to_buf(UPTIME_FILE, buf); + sscanf(buf, "%lf", &up_2); + } while ((long long) ((up_2 - up_1) * 1000.0 / up_1)); /* want under 0.1% error */ +#if ENABLE_LOCALE_SUPPORT + setlocale(LC_NUMERIC, savelocale); +#endif + jiffies = user_j + nice_j + sys_j + other_j; + seconds = (up_1 + up_2) / 2; + h = (unsigned) ((double) jiffies / seconds / smp_num_cpus); + /* actual values used by 2.4 kernels: 32 64 100 128 1000 1024 1200 */ + switch (h) { + case 9 ... 11: + Hertz = 10; /* S/390 (sometimes) */ + break; + case 18 ... 22: + Hertz = 20; /* user-mode Linux */ + break; + case 30 ... 34: + Hertz = 32; /* ia64 emulator */ + break; + case 48 ... 52: + Hertz = 50; + break; + case 58 ... 61: + Hertz = 60; + break; + case 62 ... 65: + Hertz = 64; /* StrongARM /Shark */ + break; + case 95 ... 105: + Hertz = 100; /* normal Linux */ + break; + case 124 ... 132: + Hertz = 128; /* MIPS, ARM */ + break; + case 195 ... 204: + Hertz = 200; /* normal << 1 */ + break; + case 253 ... 260: + Hertz = 256; + break; + case 393 ... 408: + Hertz = 400; /* normal << 2 */ + break; + case 790 ... 808: + Hertz = 800; /* normal << 3 */ + break; + case 990 ... 1010: + Hertz = 1000; /* ARM */ + break; + case 1015 ... 1035: + Hertz = 1024; /* Alpha, ia64 */ + break; + case 1180 ... 1220: + Hertz = 1200; /* Alpha */ + break; + default: +#ifdef HZ + Hertz = (unsigned long long) HZ; /* */ +#else + /* If 32-bit or big-endian (not Alpha or ia64), assume HZ is 100. */ + Hertz = (sizeof(long) == sizeof(int) + || htons(999) == 999) ? 100UL : 1024UL; +#endif + fprintf(stderr, "Unknown HZ value! (%d) Assume %ld.\n", h, Hertz); + } + seconds_since_boot = seconds; +} + +static void get_uptime(void) +{ + char buf[PROCPS_BUF_SIZE]; + +#if ENABLE_LOCALE_SUPPORT + char *restrict savelocale; + + savelocale = setlocale(LC_NUMERIC, NULL); + setlocale(LC_NUMERIC, "C"); +#endif + + file_to_buf(UPTIME_FILE, buf); + sscanf(buf, "%lu", &seconds_since_boot); + +#if ENABLE_LOCALE_SUPPORT + setlocale(LC_NUMERIC, savelocale); +#endif +} + +#ifndef AT_CLKTCK +#define AT_CLKTCK 17 // frequency of times() +#endif +#define NOTE_NOT_FOUND 42 + +/* for ELF executables, notes are pushed before environment and args */ +static unsigned long find_elf_note(unsigned long findme) +{ + unsigned long *ep = (unsigned long *) environ; + + while (*ep++); + while (*ep) { + if (ep[0] == findme) { + return ep[1]; + } + ep += 2; + } + return NOTE_NOT_FOUND; +} + +void init_hertz(void) +{ + init_Linux_version(); + if (linux_version_code > LINUX_VERSION(2, 4, 0)) { + Hertz = find_elf_note(AT_CLKTCK); + if (Hertz != NOTE_NOT_FOUND) { + get_uptime(); + return; + } + fputs("2.4+ kernel w/o ELF notes? -- report this\n", stderr); + } + old_Hertz_hack(); +} +#endif /* ENABLE_DESKTOP */ From Ralf.Friedl at online.de Fri Jan 4 07:28:04 2008 From: Ralf.Friedl at online.de (Ralf Friedl) Date: Fri, 04 Jan 2008 16:28:04 +0100 Subject: [PATCH] zombie processes (maybe was: init does not kill reparented processes) In-Reply-To: <477D76A6.10408@arcor.de> References: <477D76A6.10408@arcor.de> Message-ID: <477E5084.3070706@online.de> Harald K?the wrote: > Our inittab calls a startscript which is not ended during runtime, but > only when the settopbox shuts down. > I would consider this an application error and not a problem of init. > There exists a patch which is hanging around in our development tree for > ages now which we used to avoid zombie processes. > This is maybe related to some old stuff found here: > http://www.busybox.net/lists/busybox/2004-August/012422.html > This patch will solve your zombie problem, but it will only work because you don't use any other of init's functions. init will loop in waitfor(), waiting for your start script to stop, which it will not. The only difference is that with the patch init will wait for other processes. But init will not start any other processes that should run from inittab. This is probably not important for you because you don't have other actions in inittab. But the solution to your problem is not to patch init but to run you "start" script in the background or to use "once" instead of "sysinit" in your inittab. "once" actions are started by init, but init doesn't wait for them. Personally, I prefer to see the zombie processes as a strong indication for a problem with the start script to an init that doesn't run processes without any hint. Regards Ralf Friedl From vda.linux at googlemail.com Fri Jan 4 10:15:16 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jan 2008 18:15:16 +0000 Subject: [PATCH] zombie processes (maybe was: init does not kill reparented processes) In-Reply-To: <477E5084.3070706@online.de> References: <477D76A6.10408@arcor.de> <477E5084.3070706@online.de> Message-ID: <200801041815.16560.vda.linux@googlemail.com> On Friday 04 January 2008 15:28, Ralf Friedl wrote: > Harald K?the wrote: > > Our inittab calls a startscript which is not ended during runtime, but > > only when the settopbox shuts down. > > > I would consider this an application error and not a problem of init. > > > There exists a patch which is hanging around in our development tree for > > ages now which we used to avoid zombie processes. > > This is maybe related to some old stuff found here: > > http://www.busybox.net/lists/busybox/2004-August/012422.html > > > This patch will solve your zombie problem, but it will only work because > you don't use any other of init's functions. > > init will loop in waitfor(), waiting for your start script to stop, > which it will not. The only difference is that with the patch init will > wait for other processes. But init will not start any other processes > that should run from inittab. This is probably not important for you > because you don't have other actions in inittab. Yes, I think the way they Harald uses init is non-typical. He can just start that never-finishing script INSTEAD of init. However, this usage, however untypical, is valid, and init needs to wait for all orphaned children. People expect this behavior. That's why I applied the patch. -- vda From dv at vollmann.ch Fri Jan 4 10:27:31 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Fri, 04 Jan 2008 19:27:31 +0100 Subject: make all*config Message-ID: <477E7A93.4C58DC8E@vollmann.ch> Hello, are the all*config make targets still valid? In 1.9.0, allbareconfig doesn't exist (but is still listed in 'make help') and both, allyesconfig and allnoconfig don't compile... Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From martinb at zeelandnet.nl Fri Jan 4 11:48:54 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Fri, 4 Jan 2008 20:48:54 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <200801031948.37216.vda.linux@googlemail.com> Message-ID: First I have to say that I need to make a small change to some file before I can crosscompile busybox So I will give you the exact way I compile busybox so I will not forget some part (I?m not a skilled user so its possible I make a stupid error on the first part) 1- decompress busybox (1.9.0) on my linux fedora 2- with make menuconfig I deselect all except the hush (config is included) 3- run the following line to compile: make ARCH=arm CROSS_COMPILE=arm-uclinux-elf- EXTRA_CFLAGS="-D__uClinux__ -DBB_NOMMU -DSKIP_STRIP=y" LDFLAGS="-Wl,-elf2flt" install and after some time this will give me the following error: ========== /usr/local/cross-arm/20050902/lib/gcc/arm-uclinux-elf/3.4.3/../../../../arm- uclinux-elf/bin/ld.real: --gc-sections and -r may not be used together collect2: ld returned 1 exit status make: *** [busybox_unstripped] Fout 1 ========== 4- I remove the first 3 --gc-sections i find in the /scripts/trylink 5- it now finish compiling and linking on older versions I needed much more modifications (disable strip etc) and I don?t think this modifications is the source of the problem, but please if there is a more elegant way to compile please let me know I cant really use the same config because I have to use "build busybox as static binary" for the ARM But if I remove that option from i386 then it compiling and running ok on my linux about the other questions I hope I can give the correct answer: >Which libc do you build against? >If it is uclibc, post uclibc .config. I don?t really know for sure I guess its uclibc 0.9.26 I did create the toolchain from a script I got from some developer (I can send the buildscript if someone is interested, its 21KB) I did include the uclibc .config (renamed to uclibc.config) Also the .config file (renamed to bus.config) Some (probably unnecessary) thoughts I have about this 1- almost all the applets do work for me so its not a "simple" error in the toolchain 2- if it is the toolchain why does the lash script does work for me (for a active shell) 3- the hush does work for scripting , it just don?t work as a shell 4- some commands do work (like help and cd so all internal commands do work) 5- its not a "console screen problem" , all external command just give me a new console line and just don?t get executed I think its related to the fact I don?t have a MMU but then why I?m the only person with this problem ? Please give me some instruction how to give more detailed info on this issue -----Oorspronkelijk bericht----- Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] Verzonden: donderdag 3 januari 2008 20:49 Aan: busybox at busybox.net CC: Martinb_ARM_NOMMU_KISSDVD Onderwerp: Re: Hush cant replace lash for my situation On Thursday 03 January 2008 17:33, Martinb_ARM_NOMMU_KISSDVD wrote: > > After 6 months I did give the new busybox (1.9.0) a look and I try to > compile hush on my system (arm no mmu) > But sadly its giving me the exact situation it did 6 months ago > > http://www.busybox.net/lists/busybox/2007-June/027605.html > > the current hush is working much better now for scripting but I cant use is > for active shell and still need to use a old lash version (1.2.0) > If someone is interesting in solving this problem then I'm willing to give > as much feedback possible to help on this. Yes, please. That old thread drifted off-topic last time. So: does hust work for you with same .config on x86 built against glibc? Which libc do you build against? If it is uclibc, post uclibc .config. Please post busybox .config. -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: uclibc.config Type: application/octet-stream Size: 3447 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080104/bce1e611/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: bus.config Type: application/octet-stream Size: 22567 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080104/bce1e611/attachment-0003.obj From vda.linux at googlemail.com Fri Jan 4 12:09:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Fri, 4 Jan 2008 20:09:31 +0000 Subject: make all*config In-Reply-To: <477E7A93.4C58DC8E@vollmann.ch> References: <477E7A93.4C58DC8E@vollmann.ch> Message-ID: <200801042009.31771.vda.linux@googlemail.com> On Friday 04 January 2008 18:27, Detlef Vollmann wrote: > Hello, > > are the all*config make targets still valid? > In 1.9.0, allbareconfig doesn't exist (but is still listed in > 'make help') and both, allyesconfig and allnoconfig don't compile... Thanks for the report. I am removing allbareconfig, and fixing two buglets for allnoconfig/allyesconfig. allyesconfig will build only if you have SELinux include files installed. Fixes are here: http://busybox.net/downloads/fixes-1.9.0/ -- vda From tlawork at gmail.com Fri Jan 4 13:18:28 2008 From: tlawork at gmail.com (Todd Lindstrom) Date: Fri, 4 Jan 2008 15:18:28 -0600 Subject: ash and arrow keys / backspace Message-ID: <8d7708eb0801041318r44bdfa56ieaad96ee0e1791de@mail.gmail.com> I'm using busybox 1.8.2 with allnoconfig then a hodgepodge of commands added. When I press backspace, it moves the cursor, but the character is not deleted. When I press up arrow, it moves the cursor up instead of doing command line history. With an alternate busybox executable I called busybox.ti -> ash works as expected. That version was v1.2.2 and was supplied by another vendor. Since one works and the other doesnt, I would guess that this is v1.8.2source code related instead of an environment issue. Can anyone please give me a hint where I can look to solve this? thanks, TL -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080104/9288d931/attachment.htm From vda.linux at googlemail.com Fri Jan 4 16:05:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jan 2008 00:05:28 +0000 Subject: ash and arrow keys / backspace In-Reply-To: <8d7708eb0801041318r44bdfa56ieaad96ee0e1791de@mail.gmail.com> References: <8d7708eb0801041318r44bdfa56ieaad96ee0e1791de@mail.gmail.com> Message-ID: <200801050005.28614.vda.linux@googlemail.com> On Friday 04 January 2008 21:18, Todd Lindstrom wrote: > I'm using busybox 1.8.2 with allnoconfig then a hodgepodge of commands > added. > When I press backspace, it moves the cursor, but the character is not > deleted. > When I press up arrow, it moves the cursor up instead of doing command line > history. > > With an alternate busybox executable I called busybox.ti -> ash works as > expected. That version was v1.2.2 and was supplied by another vendor. > > Since one works and the other doesnt, I would guess that this is > v1.8.2source code related instead of an environment issue. > > Can anyone please give me a hint where I can look to solve this? Can you post your .config? -- vda From vda.linux at googlemail.com Fri Jan 4 16:11:19 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jan 2008 00:11:19 +0000 Subject: [PATCH] time options for ps In-Reply-To: <477E49A0.77156861@vollmann.ch> References: <477E49A0.77156861@vollmann.ch> Message-ID: <200801050011.19277.vda.linux@googlemail.com> On Friday 04 January 2008 14:58, Detlef Vollmann wrote: > Hello, > > the attached patch adds 'time' and 'etime' for ps. > It adds more than 2k (but only for CONFIG_DESKTOP) because of > the expensive computation of HZ. > If we omit support for pre-2.4 Linux, the space addition would go > way done. sizeof is wrong here: +static inline void file_to_buf(char const *filename, char *buf) +{ + if (open_read_close(filename, buf, sizeof(buf)) < 0) { + bb_error_msg_and_die(BAD_OPEN_MESSAGE); + } +} I think some serious code shrink is in order too. -- vda From vda.linux at googlemail.com Fri Jan 4 19:27:33 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 5 Jan 2008 03:27:33 +0000 Subject: [PATCH] time options for ps In-Reply-To: <477E49A0.77156861@vollmann.ch> References: <477E49A0.77156861@vollmann.ch> Message-ID: <200801050327.33499.vda.linux@googlemail.com> On Friday 04 January 2008 14:58, Detlef Vollmann wrote: > Hello, > > the attached patch adds 'time' and 'etime' for ps. > It adds more than 2k (but only for CONFIG_DESKTOP) because of > the expensive computation of HZ. > If we omit support for pre-2.4 Linux, the space addition would go > way done. I applied the patch to svn after much debloating. -- vda From cristian.ionescu-idbohrn at axis.com Sat Jan 5 13:00:52 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sat, 5 Jan 2008 22:00:52 +0100 (CET) Subject: ps and username size Message-ID: <0801052121440.17543@somehost> Noticed that several usernames on my debian sid box are longer than 8 bytes: ,---- | Debian-exim:x:102:102::/var/spool/exim4:/bin/false | messagebus:x:103:104::/var/run/dbus:/bin/false | fetchmail:x:107:65534::/var/lib/fetchmail:/bin/sh | debarchiver:x:109:109:Deb archiving tool,,,:/var/lib/debarchiver:/bin/false | smokeping:x:127:127:SmokePing daemon,,,:/var/lib/smokeping:/bin/false | haldaemon:x:132:124:Hardware abstraction layer,,,:/home/haldaemon:/bin/false | email-reminder:x:1002:1003:Email-reminder mailer,,,:/var/spool/email-reminder:/bin/bash `---- ps from procps-3.2.7-5 shows such users using the uid instead of username: ,---- | 103 4469 0.0 0.0 2764 888 ? Ss 15:52 0:00 /usr/bin/dbus-d | 127 4969 0.0 0.3 15468 12364 ? Ss 15:52 0:00 /usr/sbin/smoke | 132 5241 0.0 0.1 5284 3352 ? Ss 15:52 0:00 /usr/sbin/hald | 132 5273 0.0 0.0 2224 908 ? S 15:52 0:00 hald-addon-acpi | 127 27372 0.0 0.0 2692 920 ? S 21:28 0:00 /usr/bin/fping `---- bb-ps shifts 'VSZ STAT COMMAND' a few columns, adjusting to the username string size: ,---- | 4469 messagebus 2764 S /usr/bin/dbus-daemon --system | 4969 smokeping 15468 S /usr/sbin/smokeping [FPing] | 5241 haldaemon 5284 S /usr/sbin/hald | 5265 root 3248 S hald-addon-input: Listening on /dev/input/event4 /dev | 5273 haldaemon 2224 S hald-addon-acpi: listening on acpid socket /var/run/ `---- The attached patch attempts to immitate procps-3.2.7-5 behaviour, so that: # ./busybox_unstripped ps shows: ,---- | PID USER VSZ STAT COMMAND | 4469 103 2764 S /usr/bin/dbus-daemon --system | 4969 127 15468 S /usr/sbin/smokeping [FPing] | 5241 132 5284 S /usr/sbin/hald | 5273 132 2224 S hald-addon-acpi: listening on acpid socket /var/run/ `---- similar to: # ps -A -o pid,user,vsz,stat,commandps -A -o pid,user,vsz,stat,command ,---- | PID USER VSZ STAT COMMAND | 4469 103 2764 Ss /usr/bin/dbus-daemon --system | 4969 127 15468 Ss /usr/sbin/smokeping [FPing] | 5241 132 5284 Ss /usr/sbin/hald | 5273 132 2224 S hald-addon-acpi: listening on acpid socket /var/run/ `---- There are still some differences the way STAT is shown. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ps.c.patch Type: text/x-diff Size: 967 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080105/b8792f70/attachment.bin From vda.linux at googlemail.com Sat Jan 5 19:24:27 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jan 2008 03:24:27 +0000 Subject: ps and username size In-Reply-To: <0801052121440.17543@somehost> References: <0801052121440.17543@somehost> Message-ID: <200801060324.28126.vda.linux@googlemail.com> On Saturday 05 January 2008 21:00, Cristian Ionescu-Idbohrn wrote: > Noticed that several usernames on my debian sid box are longer than 8 > bytes: > > ,---- > | Debian-exim:x:102:102::/var/spool/exim4:/bin/false > | messagebus:x:103:104::/var/run/dbus:/bin/false > | fetchmail:x:107:65534::/var/lib/fetchmail:/bin/sh > | debarchiver:x:109:109:Deb archiving tool,,,:/var/lib/debarchiver:/bin/false > | smokeping:x:127:127:SmokePing daemon,,,:/var/lib/smokeping:/bin/false > | haldaemon:x:132:124:Hardware abstraction layer,,,:/home/haldaemon:/bin/false > | email-reminder:x:1002:1003:Email-reminder mailer,,,:/var/spool/email-reminder:/bin/bash > `---- > > ps from procps-3.2.7-5 shows such users using the uid instead of username: > > ,---- > | 103 4469 0.0 0.0 2764 888 ? Ss 15:52 0:00 /usr/bin/dbus-d > | 127 4969 0.0 0.3 15468 12364 ? Ss 15:52 0:00 /usr/sbin/smoke > | 132 5241 0.0 0.1 5284 3352 ? Ss 15:52 0:00 /usr/sbin/hald > | 132 5273 0.0 0.0 2224 908 ? S 15:52 0:00 hald-addon-acpi > | 127 27372 0.0 0.0 2692 920 ? S 21:28 0:00 /usr/bin/fping > `---- > > bb-ps shifts 'VSZ STAT COMMAND' a few columns, adjusting to the username > string size: > > ,---- > | 4469 messagebus 2764 S /usr/bin/dbus-daemon --system > | 4969 smokeping 15468 S /usr/sbin/smokeping [FPing] > | 5241 haldaemon 5284 S /usr/sbin/hald > | 5265 root 3248 S hald-addon-input: Listening on /dev/input/event4 /dev > | 5273 haldaemon 2224 S hald-addon-acpi: listening on acpid socket /var/run/ > `---- Thanks for the report. Using %-8.8s instead of %-8s fixes this. I am also fixing VSZ overflow with large VSZs. Will commit changes to svn in a minute. -- vda From vda.linux at googlemail.com Sat Jan 5 19:52:23 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jan 2008 03:52:23 +0000 Subject: Hush cant replace lash for my situation In-Reply-To: References: Message-ID: <200801060352.24068.vda.linux@googlemail.com> On Friday 04 January 2008 19:48, Martinb_ARM_NOMMU_KISSDVD wrote: > First I have to say that I need to make a small change to some file before I > can crosscompile busybox > So I will give you the exact way I compile busybox so I will not forget some > part (I?m not a skilled user so its possible I make a stupid error on the > first part) > > 1- decompress busybox (1.9.0) on my linux fedora > 2- with make menuconfig I deselect all except the hush (config is included) > 3- run the following line to compile: > > make ARCH=arm CROSS_COMPILE=arm-uclinux-elf- > EXTRA_CFLAGS="-D__uClinux__ -DBB_NOMMU -DSKIP_STRIP=y" > LDFLAGS="-Wl,-elf2flt" install > > and after some time this will give me the following error: > > ========== > /usr/local/cross-arm/20050902/lib/gcc/arm-uclinux-elf/3.4.3/../../../../arm- > uclinux-elf/bin/ld.real: --gc-sections and -r may not be used together > collect2: ld returned 1 exit status > make: *** [busybox_unstripped] Fout 1 > ========== > > 4- I remove the first 3 --gc-sections i find in the /scripts/trylink > 5- it now finish compiling and linking > > on older versions I needed much more modifications (disable strip etc) and I > don?t think this modifications is the source of the problem, but please if > there is a more elegant way to compile please let me know It seems you do everything right, apard from -DBB_NOMMU. busybox does not expect that variable to be set like that. I typically just replace #if defined __UCLIBC__ && __UCLIBC_MAJOR__ >= 0 && __UCLIBC_MINOR__ >= 9 && \ __UCLIBC_SUBLEVEL__ > 28 && !defined __ARCH_USE_MMU__ by #if 1 in platform.h. Try doing that, and not passing -DBB_NOMMU. This is unlikely to be a reason for your problems, tho. On the more extended note, I think it makes sense for you to learn how to build YOUR OWN uclibc and toolchain instead of using pre-packaged one. This can help checking whether this is a bug in older uclibc, etc. Start from: http://busybox.net/~vda/HOWTO_bbox_with_uclibc.txt I will try to help you if you hit a problem; this will also help making this HOWTO more solid. If you will do it and need to ask questions, start a new thread (do not reply to this message). > I cant really use the same config because I have to use "build busybox as > static binary" for the ARM > > But if I remove that option from i386 then it compiling and running ok on my > linux I built busybox against uclibc-0.9.29 for x86 with your .config (with NOMMU hacked to 1) and it works for me (my uclibc's .config is different, though). > about the other questions I hope I can give the correct answer: > > >Which libc do you build against? > >If it is uclibc, post uclibc .config. > > I don?t really know for sure > I guess its uclibc 0.9.26 Quite old. > I did create the toolchain from a script I got from some developer > (I can send the buildscript if someone is interested, its 21KB) > I did include the uclibc .config (renamed to uclibc.config) > Also the .config file (renamed to bus.config) > > Some (probably unnecessary) thoughts I have about this > > 1- almost all the applets do work for me so its not a "simple" error in the > toolchain > 2- if it is the toolchain why does the lash script does work for me (for a > active shell) > 3- the hush does work for scripting , it just don?t work as a shell > 4- some commands do work (like help and cd so all internal commands do work) > 5- its not a "console screen problem" , all external command just give me a > new console line and just don?t get executed > > I think its related to the fact I don?t have a MMU but then why I?m the only > person with this problem ? Well, for me NOMMU build works. Let's try to figure out what's going on (where it hits the problem). hush.c has the following at the top: /* If you comment out one of these below, it will be #defined later * to perform debug printfs to stderr: */ #define debug_printf(...) do {} while (0) /* Finer-grained debug switches */ #define debug_printf_parse(...) do {} while (0) #define debug_print_tree(a, b) do {} while (0) #define debug_printf_exec(...) do {} while (0) #define debug_printf_jobs(...) do {} while (0) #define debug_printf_expand(...) do {} while (0) #define debug_printf_clean(...) do {} while (0) Comment out define debug_printf_exec: //#define debug_printf_exec(...) do {} while (0) and rebuild busybox. Now run it and type "ls". For me, it shows this: $ ls parse_stream_outer: run_list run_list entered : run_list_real with 1 members run_list_real start lvl 1 : rword=0 if_code=0 next_if_code=0 skip_more=12 : run_pipe_real with 1 members run_pipe_real start: single_fg=1 : pipe member 'ls' '(null)'... execing 'ls' AUTHORS TODO_config_nommu console-tools ipsvd runit Config.in applets coreutils libbb scripts INSTALL arch debianutils libpwdgrp selinux LICENSE archival docs loginutils shell Makefile busybox e2fsprogs miscutils sysklogd Makefile.custom busybox_ldscript editors modutils testsuite Makefile.flags busybox_old examples networking util-linux Makefile.help busybox_unstripped findutils procps README busybox_unstripped.map include ps1 TODO busybox_unstripped.out init ps2 run_pipe_real return -1 : checkjobs returned 0 : setting last_return_code=0 : rword=0 if_code=0 next_if_code=0 skip_more=12 run_list_real lvl 1 return 0 run_list return 0 $ What do you see? -- vda From vda.linux at googlemail.com Sat Jan 5 22:28:47 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sun, 6 Jan 2008 06:28:47 +0000 Subject: [PATCH] coreutils tac (was: coreutils tac) In-Reply-To: <1199287382.6084.0.camel@nc.nor.wtbts.org> References: <1198572349.7769.2.camel@nc.nor.wtbts.org> <200712290829.34342.farmatito@tiscali.it> <1199287382.6084.0.camel@nc.nor.wtbts.org> Message-ID: <200801060628.47416.vda.linux@googlemail.com> On Wednesday 02 January 2008 15:23, Natanael Copa wrote: > Denys, whats the status on the tac patch? Version which does inversion in memory is appled to svn. It handles non terminated last line the same as coreutils, but mishandles NULs. -- vda From emaildq at yahoo.com.cn Sun Jan 6 00:15:47 2008 From: emaildq at yahoo.com.cn (zhuzhu) Date: Sun, 6 Jan 2008 16:15:47 +0800 (CST) Subject: I can't log in Message-ID: <300726.30993.qm@web15808.mail.cnb.yahoo.com> dear sir: I built my own filesystems with busybox ,use nfs to boot,and copy "group passwd shadow"to /myrootfs/etc.but I can't login with my user name,when I type my login name,:zhu.I get" Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart.",it enve didn't ask me for password.,thank you for your help. best regards zhudq here is the infomation: Probing IDE interface ide0... NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) eth0: Phy @ 0x0, type LXT971 (0x001378e2) IP-Config: Gateway not on directly connected network. NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 10.212.43.54 Looking up port of RPC 100005/1 on 10.212.43.54 VFS: Mounyted root (nfs fesystem). Foreeing unused kemory: 76k init init started: BusyBox v1.1.2 (2008.01.05-09:08+0000) multi-call binary Starting pid 11, console /dev/console: '/etc/init.d/rcS' Bummer, could not run '/etc/init.d/rcS': No such file or directory Bummer, could not run '/etc/init.d/rcS': No such file or directory Starting pid 12, console /dev/console: '/sbin/getty' icecube login: zju Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart. Starting pid 13, console /dev/console: '/sbin/getty' icecube login: root Process '/sbin/getty 115200 ttyS0' (pid 13) exited. Scheduling it for restart. Starting pid 14, console /dev/console: '/sbin/getty' --------------------------------- ??????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080106/51347f7c/attachment.htm From farmatito at tiscali.it Sun Jan 6 01:31:07 2008 From: farmatito at tiscali.it (Tito) Date: Sun, 6 Jan 2008 10:31:07 +0100 Subject: [PATCH] coreutils tac (was: coreutils tac) In-Reply-To: <200801060628.47416.vda.linux@googlemail.com> References: <1198572349.7769.2.camel@nc.nor.wtbts.org> <1199287382.6084.0.camel@nc.nor.wtbts.org> <200801060628.47416.vda.linux@googlemail.com> Message-ID: <200801061031.07188.farmatito@tiscali.it> On Sunday 06 January 2008 07:28:47 Denys Vlasenko wrote: > On Wednesday 02 January 2008 15:23, Natanael Copa wrote: > > Denys, whats the status on the tac patch? > > Version which does inversion in memory is appled to svn. > It handles non terminated last line the same as coreutils, > but mishandles NULs. Hi, Denis, did you forget svn add again? :-) Why it mishandles NULs? I thought that i've got it right in version 2 of my patch (attached): ??????????????/* Get line and add it to the start of the temp linked list. */ ????????????????while ((line = xmalloc_fgets(f))) { ????????????????????????if (temp_list && !last_char_is(temp_list->data, '\n')) ????????????????????????????????/* Last line ended with '\0' so concatenate them. */ ???????????????????????????????? temp_list->data = xasprintf("%s%s", temp_list->data, line); ????????????????????????else ????????????????????????????????llist_add_to(&temp_list, line);? ????????????????} this was the test file i used (attached): 055 056 057 000 057 056 055 010 result is: GNU tac tac prova4 789987 busybox ./busybox tac prova4 789987 Ciao, TIto > -- > vda > -------------- next part -------------- 789987 -------------- next part -------------- A non-text attachment was scrubbed... Name: tac.c Type: text/x-csrc Size: 1896 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080106/80c2d501/attachment-0001.c From landau_alex at yahoo.com Sun Jan 6 04:42:12 2008 From: landau_alex at yahoo.com (Alex Landau) Date: Sun, 6 Jan 2008 04:42:12 -0800 (PST) Subject: syslogd Message-ID: <597123.96732.qm@web62506.mail.re1.yahoo.com> Hi, As a side effect of my problems with syslogd described below, I found a bug (return value from shmat() checked for error incorrectly), which is fixed by the attached patch. I'm running on NOMMU and using busybox 1.7 (and checked the relevant changes in syslogd.c till trunk head - none seems to be related). The problem itself: Once in a while (about once a week), syslogd crashes. I traced the point of the crash, and it is in log_to_shmem() in the "memcpy(G.shbuf->data + old_tail, msg, k);" line (line no. 268 in trunk head). The pointer (G.shbuf->data + old_tail) points to a bizarre place (very far from the shm area shown in /proc/pid/maps), and naturally trying to write there crashes syslog. I thought the problem happens due to the circular buffer overflowing, but running "logger" several times in order to fill the whole buffer didn't crash syslog, so this does not seem to be related. I didn't succeed in finding the cause of the crash (memory corruption? something overwriting G.shbuf?), and would appreciate any help. Oh, and how did I find the "shmat() return value" bug? If after syslogd crashes, I (or actually runsv) runs it again, it crashes at the memset in ipcsyslog_init() trying to write to 0xFFFFFFFF. Maybe shmat() failed due to the crash of the previous instance of syslogd, for which the kernel probably haven't released all resources (NOMMU, remember), maybe not... But shmget() succeeded and that's strange. Anyway, any help will be greatly appreciated. Thanks, Alex ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- A non-text attachment was scrubbed... Name: syslogd.diff Type: text/x-diff Size: 11604 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080106/ba29b031/attachment.bin From dv at vollmann.ch Sun Jan 6 04:58:55 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Sun, 06 Jan 2008 13:58:55 +0100 Subject: [PATCH] time options for ps References: <477E49A0.77156861@vollmann.ch> <200801050011.19277.vda.linux@googlemail.com> Message-ID: <4780D08F.56873B4F@vollmann.ch> Denys Vlasenko wrote: > sizeof is wrong here: > > +static inline void file_to_buf(char const *filename, char *buf) > +{ > + if (open_read_close(filename, buf, sizeof(buf)) < 0) { > + bb_error_msg_and_die(BAD_OPEN_MESSAGE); > + } > +} Oops, mea culpa :-( This happened when I read the coding guidelines and converted the macro to an inline function... Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From dv at vollmann.ch Sun Jan 6 04:59:34 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Sun, 06 Jan 2008 13:59:34 +0100 Subject: [PATCH] time options for ps References: <477E49A0.77156861@vollmann.ch> <200801050327.33499.vda.linux@googlemail.com> Message-ID: <4780D0B6.276C612B@vollmann.ch> Denys Vlasenko wrote: > > On Friday 04 January 2008 14:58, Detlef Vollmann wrote: > > Hello, > > > > the attached patch adds 'time' and 'etime' for ps. > > It adds more than 2k (but only for CONFIG_DESKTOP) because of > > the expensive computation of HZ. > > If we omit support for pre-2.4 Linux, the space addition would go > > way done. > > I applied the patch to svn after much debloating. Thanks, looks much nicer now :-) Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From farmatito at tiscali.it Sun Jan 6 05:19:42 2008 From: farmatito at tiscali.it (Tito) Date: Sun, 6 Jan 2008 14:19:42 +0100 Subject: syslogd In-Reply-To: <597123.96732.qm@web62506.mail.re1.yahoo.com> References: <597123.96732.qm@web62506.mail.re1.yahoo.com> Message-ID: <200801061419.42529.farmatito@tiscali.it> On Sunday 06 January 2008 13:42:12 Alex Landau wrote: > Hi, > > As a side effect of my problems with syslogd described below, I found a bug (return value from shmat() > checked for error incorrectly), which is fixed by the attached patch. > > I'm running on NOMMU and using busybox 1.7 (and checked the relevant changes in syslogd.c till trunk head - none seems to be related). > The problem itself: Once in a while (about once a week), syslogd crashes. I traced the point of the crash, > and it is in log_to_shmem() in the "memcpy(G.shbuf->data + old_tail, msg, k);" line (line no. 268 in trunk head). > > The pointer (G.shbuf->data + old_tail) points to a bizarre place (very far from the shm area shown in /proc/pid/maps), and naturally trying to write there crashes syslog. I thought the problem happens due to the circular buffer overflowing, but running "logger" several times in order to fill the whole buffer didn't crash syslog, so this does not seem to be related. > > I didn't succeed in finding the cause of the crash (memory corruption? something overwriting G.shbuf?), and would appreciate any help. > > Oh, and how did I find the "shmat() return value" bug? If after syslogd crashes, I (or actually runsv) runs it again, it crashes at the memset in ipcsyslog_init() trying to write to 0xFFFFFFFF. Maybe shmat() failed due to the crash of the previous instance of syslogd, for which the kernel probably haven't released all resources (NOMMU, remember), maybe not... But shmget() succeeded and that's strange. > > Anyway, any help will be greatly appreciated. > Thanks, > Alex > > > Alex, you attached a man page rather than the patch. :-) Ciao, Tito From rep.dot.nop at gmail.com Sun Jan 6 05:57:48 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sun, 6 Jan 2008 14:57:48 +0100 Subject: svn commit: trunk/busybox: coreutils docs include In-Reply-To: <20080106062718.75AE412C58A@busybox.net> References: <20080106062718.75AE412C58A@busybox.net> Message-ID: <20080106135748.GV17973@aon.at> On Sat, Jan 05, 2008 at 10:27:18PM -0800, vda at busybox.net wrote: >Author: vda >Date: 2008-01-05 22:27:17 -0800 (Sat, 05 Jan 2008) >New Revision: 20806 > >Log: >tac: new applet. ~240 bytes. > >Copyright (C) 2003 Yang Xiaopeng >Copyright (C) 2007 Natanael Copa >Copyright (C) 2007 Tito Ragusa > > > >Modified: > trunk/busybox/coreutils/Config.in > trunk/busybox/coreutils/Kbuild > trunk/busybox/docs/nofork_noexec.txt > trunk/busybox/include/applets.h > trunk/busybox/include/usage.h vda, This sounds like you forgot to svn add coreutils/tac.c Didn't look at it, but does this add a third impl of visible() (see TODO for stty/catv) ? From dv at vollmann.ch Sun Jan 6 06:12:32 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Sun, 06 Jan 2008 15:12:32 +0100 Subject: ps and username size References: <0801052121440.17543@somehost> <200801060324.28126.vda.linux@googlemail.com> Message-ID: <4780E1D0.60EE8CDE@vollmann.ch> Denys Vlasenko wrote: > Thanks for the report. Using %-8.8s instead of %-8s fixes this. > > I am also fixing VSZ overflow with large VSZs. > > Will commit changes to svn in a minute. @@ -188,7 +188,10 @@ static void put_lu(char *buf, int size, unsigned long u) { char buf5[5]; - smart_ulltoa5( ((unsigned long long)u) << 10, buf5); + + /* see http://en.wikipedia.org/wiki/Tera */ + smart_ulltoa4( (u, buf5, " mgtpezy"); ^^ This line contains a type, leading to: procps/ps.c: In function `put_lu': procps/ps.c:193: warning: left-hand operand of comma expression has no effect procps/ps.c:193: warning: left-hand operand of comma expression has no effect procps/ps.c:193: parse error before ';' token Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From landau_alex at yahoo.com Sun Jan 6 06:10:52 2008 From: landau_alex at yahoo.com (Alex Landau) Date: Sun, 6 Jan 2008 06:10:52 -0800 (PST) Subject: syslogd Message-ID: <99937.91232.qm@web62514.mail.re1.yahoo.com> ----- Original Message ---- > From: Tito > To: busybox at busybox.net > Cc: Alex Landau > Sent: Sunday, January 6, 2008 3:19:42 PM > Subject: Re: syslogd > > > [snip] > > > Alex, you attached a man page rather than the patch. :-) > > Ciao, > Tito > Right :-) Sorry. The patch is attached. Alex ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -------------- next part -------------- A non-text attachment was scrubbed... Name: syslogd.diff Type: text/x-diff Size: 325 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080106/215826d4/attachment.bin From cristian.ionescu-idbohrn at axis.com Sun Jan 6 06:16:47 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 6 Jan 2008 15:16:47 +0100 (CET) Subject: ps and username size In-Reply-To: <200801060324.28126.vda.linux@googlemail.com> References: <0801052121440.17543@somehost> <200801060324.28126.vda.linux@googlemail.com> Message-ID: <0801061433450.10489@somehost> On Sun, 6 Jan 2008, Denys Vlasenko wrote: > Thanks for the report. Using %-8.8s instead of %-8s fixes this. > > I am also fixing VSZ overflow with large VSZs. > > Will commit changes to svn in a minute. Thanks. The attached patch properly adjusts the columns to the header and immitates debian ps from procps-3.2.7-5. bb-ps (revision 20806) PID USER VSZ STAT COMMAND 1 root 2080 S init [2] 2 root 0 SW< [kthreadd] 3 root 0 SW< [migration/0] 4 root 0 SWN [ksoftirqd/0] 5 root 0 SW< [watchdog/0] 6 root 0 SW< [migration/1] 7 root 0 SWN [ksoftirqd/1] 8 root 0 SW< [watchdog/1] 9 root 0 SW< [events/0] # ps -A -o pid,user,vsz,stat,command | head PID USER VSZ STAT COMMAND 1 root 2080 Ss init [2] 2 root 0 S< [kthreadd] 3 root 0 S< [migration/0] 4 root 0 SN [ksoftirqd/0] 5 root 0 S< [watchdog/0] 6 root 0 S< [migration/1] 7 root 0 SN [ksoftirqd/1] 8 root 0 S< [watchdog/1] 9 root 0 S< [events/0] patched bb-ps PID USER VSZ STAT COMMAND 1 root 2080 S init [2] 2 root 0 SW< [kthreadd] 3 root 0 SW< [migration/0] 4 root 0 SWN [ksoftirqd/0] 5 root 0 SW< [watchdog/0] 6 root 0 SW< [migration/1] 7 root 0 SWN [ksoftirqd/1] 8 root 0 SW< [watchdog/1] 9 root 0 SW< [events/0] I'm a bit unsure about the selinux adjustments. The current svn chops of long usernames to 8 chars. That may create confusion if the output from ps is in any way used to identify process owners. Users: 'longnameA' and 'longnameB' will both be displayed as 'longname'. Please consider replacing usernames longer than 8 chars with the corresponding uids. That will make them unique in the ps list. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ps.c.patch Type: text/x-diff Size: 890 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080106/648b7179/attachment.bin From cristian.ionescu-idbohrn at axis.com Sun Jan 6 06:35:30 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Sun, 6 Jan 2008 15:35:30 +0100 (CET) Subject: ps and username size In-Reply-To: <4780E1D0.60EE8CDE@vollmann.ch> References: <0801052121440.17543@somehost> <200801060324.28126.vda.linux@googlemail.com> <4780E1D0.60EE8CDE@vollmann.ch> Message-ID: <0801061529260.10489@somehost> On Sun, 6 Jan 2008, Detlef Vollmann wrote: > + smart_ulltoa4( (u, buf5, " mgtpezy"); > ^^ > This line contains a type, leading to: > procps/ps.c: In function `put_lu': > procps/ps.c:193: warning: left-hand operand of comma expression has no effect > procps/ps.c:193: warning: left-hand operand of comma expression has no effect > procps/ps.c:193: parse error before ';' token Just noticed some indentation whitespace damage in procps/ps.c. Attached patch gives an idea on which areas need reindenting. Cheers, -- Cristian -------------- next part -------------- A non-text attachment was scrubbed... Name: ps.c.2.patch Type: text/x-diff Size: 2838 bytes Desc: Url : http://busybox.net/lists/busybox/attachments/20080106/c62966b9/attachment.bin From dv at vollmann.ch Sun Jan 6 08:05:05 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Sun, 06 Jan 2008 17:05:05 +0100 Subject: do ... while(0) optimization problem Message-ID: <4780FC31.40D92E45@vollmann.ch> Hello, in util-linux/fdisk.c, the macro #define INIT_G() do { \ PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ sector_size = DEFAULT_SECTOR_SIZE; \ sector_offset = 1; \ g_partitions = 4; \ display_in_cyl_units = 1; \ units_per_sector = 1; \ } while (0) seems to get partly optimized away in my gcc (GCC) 3.2.2. I get a segmentation fault and it turns out that ptr_to_globals is 0. Rewriting the macro to #define INIT_G() ( \ PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ sector_size = DEFAULT_SECTOR_SIZE, \ sector_offset = 1, \ g_partitions = 4, \ display_in_cyl_units = 1, \ units_per_sector = 1) works fine... Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From vapier at gentoo.org Sun Jan 6 10:14:18 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 13:14:18 -0500 Subject: do ... while(0) optimization problem In-Reply-To: <4780FC31.40D92E45@vollmann.ch> References: <4780FC31.40D92E45@vollmann.ch> Message-ID: <200801061314.19491.vapier@gentoo.org> On Sunday 06 January 2008, Detlef Vollmann wrote: > in util-linux/fdisk.c, the macro > > #define INIT_G() do { \ > PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ > sector_size = DEFAULT_SECTOR_SIZE; \ > sector_offset = 1; \ > g_partitions = 4; \ > display_in_cyl_units = 1; \ > units_per_sector = 1; \ > } while (0) > > seems to get partly optimized away in my gcc (GCC) 3.2.2. > I get a segmentation fault and it turns out that ptr_to_globals is 0. so fix your gcc ? the point of do { ... } while (0) is to provide proper wrapping context that can be used anywhere that a single statement can. sane gcc will expand all of the code within without the do/while part because it's a nop. > Rewriting the macro to > > #define INIT_G() ( \ > PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ > sector_size = DEFAULT_SECTOR_SIZE, \ > sector_offset = 1, \ > g_partitions = 4, \ > display_in_cyl_units = 1, \ > units_per_sector = 1) > > works fine... you could always compare the disassembly output, but considering how ancient your gcc is, that sounds like a waste of time -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080106/ec5215b7/attachment.pgp From loic.grenie at gmail.com Sun Jan 6 10:28:15 2008 From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=) Date: Sun, 6 Jan 2008 19:28:15 +0100 Subject: do ... while(0) optimization problem In-Reply-To: <200801061314.19491.vapier@gentoo.org> References: <4780FC31.40D92E45@vollmann.ch> <200801061314.19491.vapier@gentoo.org> Message-ID: <9b06e8d20801061028i38efce6ai3156b46318858e9a@mail.gmail.com> 2008/1/6, Mike Frysinger : > On Sunday 06 January 2008, Detlef Vollmann wrote: > > in util-linux/fdisk.c, the macro > > > > #define INIT_G() do { \ > > PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ > > sector_size = DEFAULT_SECTOR_SIZE; \ > > sector_offset = 1; \ > > g_partitions = 4; \ > > display_in_cyl_units = 1; \ > > units_per_sector = 1; \ > > } while (0) > > > > seems to get partly optimized away in my gcc (GCC) 3.2.2. > > I get a segmentation fault and it turns out that ptr_to_globals is 0. > > so fix your gcc ? the point of do { ... } while (0) is to provide proper > wrapping context that can be used anywhere that a single statement can. sane > gcc will expand all of the code within without the do/while part because it's > a nop. > > > Rewriting the macro to > > > > #define INIT_G() ( \ > > PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ > > sector_size = DEFAULT_SECTOR_SIZE, \ > > sector_offset = 1, \ > > g_partitions = 4, \ > > display_in_cyl_units = 1, \ > > units_per_sector = 1) > > > > works fine... > > you could always compare the disassembly output, but considering how ancient > your gcc is, that sounds like a waste of time > -mike You can also rewrite the macro do { statements; break; } while(1) Ancient SunOS' cc's are known to break the do { } while(0); construct. It does not break the preceeding one. I don't remember anything about gcc though. Lo?c Greni? From vapier at gentoo.org Sun Jan 6 10:41:07 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Sun, 6 Jan 2008 13:41:07 -0500 Subject: do ... while(0) optimization problem In-Reply-To: <9b06e8d20801061028i38efce6ai3156b46318858e9a@mail.gmail.com> References: <4780FC31.40D92E45@vollmann.ch> <200801061314.19491.vapier@gentoo.org> <9b06e8d20801061028i38efce6ai3156b46318858e9a@mail.gmail.com> Message-ID: <200801061341.08266.vapier@gentoo.org> On Sunday 06 January 2008, Lo?c Greni? wrote: > 2008/1/6, Mike Frysinger : > > On Sunday 06 January 2008, Detlef Vollmann wrote: > > > in util-linux/fdisk.c, the macro > > > > > > #define INIT_G() do { \ > > > PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ > > > sector_size = DEFAULT_SECTOR_SIZE; \ > > > sector_offset = 1; \ > > > g_partitions = 4; \ > > > display_in_cyl_units = 1; \ > > > units_per_sector = 1; \ > > > } while (0) > > > > > > seems to get partly optimized away in my gcc (GCC) 3.2.2. > > > I get a segmentation fault and it turns out that ptr_to_globals is 0. > > > > so fix your gcc ? the point of do { ... } while (0) is to provide proper > > wrapping context that can be used anywhere that a single statement can. > > sane gcc will expand all of the code within without the do/while part > > because it's a nop. > > > > > Rewriting the macro to > > > > > > #define INIT_G() ( \ > > > PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ > > > sector_size = DEFAULT_SECTOR_SIZE, \ > > > sector_offset = 1, \ > > > g_partitions = 4, \ > > > display_in_cyl_units = 1, \ > > > units_per_sector = 1) > > > > > > works fine... > > > > you could always compare the disassembly output, but considering how > > ancient your gcc is, that sounds like a waste of time > > You can also rewrite the macro > > do { > statements; > break; > } while(1) > > Ancient SunOS' cc's are known to break the do { } while(0); construct. > It does not break the preceeding one. I don't remember anything about > gcc though. that'd be interesting to see if it makes a difference here ... but considering the common convention is (0) and the target busybox environment is not old/busted SunOS, i dont think we should be catering to busted compilers. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080106/c915369b/attachment.pgp From loic.grenie at gmail.com Sun Jan 6 10:49:56 2008 From: loic.grenie at gmail.com (=?ISO-8859-1?Q?Lo=EFc_Greni=E9?=) Date: Sun, 6 Jan 2008 19:49:56 +0100 Subject: do ... while(0) optimization problem In-Reply-To: <200801061341.08266.vapier@gentoo.org> References: <4780FC31.40D92E45@vollmann.ch> <200801061314.19491.vapier@gentoo.org> <9b06e8d20801061028i38efce6ai3156b46318858e9a@mail.gmail.com> <200801061341.08266.vapier@gentoo.org> Message-ID: <9b06e8d20801061049y189f5b0bra1787dd76f6cd819@mail.gmail.com> 2008/1/6, Mike Frysinger : > On Sunday 06 January 2008, Lo?c Greni? wrote: > > 2008/1/6, Mike Frysinger : > > > On Sunday 06 January 2008, Detlef Vollmann wrote: > > > > in util-linux/fdisk.c, the macro > > > > > > > > #define INIT_G() do { \ > > > > PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ > > > > sector_size = DEFAULT_SECTOR_SIZE; \ > > > > sector_offset = 1; \ > > > > g_partitions = 4; \ > > > > display_in_cyl_units = 1; \ > > > > units_per_sector = 1; \ > > > > } while (0) > > > > > > > > seems to get partly optimized away in my gcc (GCC) 3.2.2. > > > > I get a segmentation fault and it turns out that ptr_to_globals is 0. > > > > > > so fix your gcc ? the point of do { ... } while (0) is to provide proper > > > wrapping context that can be used anywhere that a single statement can. > > > sane gcc will expand all of the code within without the do/while part > > > because it's a nop. > > > > > > > Rewriting the macro to > > > > > > > > #define INIT_G() ( \ > > > > PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ > > > > sector_size = DEFAULT_SECTOR_SIZE, \ > > > > sector_offset = 1, \ > > > > g_partitions = 4, \ > > > > display_in_cyl_units = 1, \ > > > > units_per_sector = 1) > > > > > > > > works fine... > > > > > > you could always compare the disassembly output, but considering how > > > ancient your gcc is, that sounds like a waste of time > > > > You can also rewrite the macro > > > > do { > > statements; > > break; > > } while(1) > > > > Ancient SunOS' cc's are known to break the do { } while(0); construct. > > It does not break the preceeding one. I don't remember anything about > > gcc though. > > that'd be interesting to see if it makes a difference here ... but considering > the common convention is (0) and the target busybox environment is not > old/busted SunOS, i dont think we should be catering to busted compilers. Sorry I was not clear enough: you are perfectly right that the compiler is broken and should be changed. However, another solution for this problem in the case of the OP was to change the macro as indicated. I do not think it would be a good idea to change busybox: do { } while(0) is correct and works for nearly every compiler. Lo?c Greni? From martinb at zeelandnet.nl Sun Jan 6 14:03:59 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Sun, 6 Jan 2008 23:03:59 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <200801060352.24068.vda.linux@googlemail.com> Message-ID: I did build the toolchain but i used a script, i will try to learn to build my own uclibc but if i look at the buildscript and all the patches the developers have used then i think i will never be able to do this (but i will try, and will bug you on a new thread if im stuck) I did remove the -DBB_NOMMU (dont remember why i ever put it ther in the first place) Did Comment out define debug_printf_exec and recompile run it and type "ls". For me, it shows this: =============================================== /hdd/shell # ls parse_stream_outer: run_list run_list entered : run_list_real with 1 members run_list_real start lvl 1 : rword=0 if_code=0 next_if_code=0 skip_more=12 : run_pipe_real with 1 members run_pipe_real start: single_fg=1 : pipe member 'ls' '(null)'... run_pipe_real return -1 : checkjobs returned 0 : setting last_return_code=0 : rword=0 if_code=0 next_if_code=0 skip_more=12 run_list_real lvl 1 return 0 run_list return 0 ================================================ If i do the same on lash i get ================================================ /hdd/shell # ls busybox hush lash msh stage2 ================================================ i have a criple strace but im not sure if this wil give more help? -----Oorspronkelijk bericht----- Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] Verzonden: zondag 6 januari 2008 4:52 Aan: Martinb_ARM_NOMMU_KISSDVD CC: busybox at busybox.net Onderwerp: Re: Hush cant replace lash for my situation (removed some) .. On the more extended note, I think it makes sense for you to learn how to build YOUR OWN uclibc and toolchain instead of using pre-packaged one. This can help checking whether this is a bug in older uclibc, etc. Start from: http://busybox.net/~vda/HOWTO_bbox_with_uclibc.txt I will try to help you if you hit a problem; this will also help making this HOWTO more solid. If you will do it and need to ask questions, start a new thread (do not reply to this message). .. Let's try to figure out what's going on (where it hits the problem). hush.c has the following at the top: /* If you comment out one of these below, it will be #defined later * to perform debug printfs to stderr: */ #define debug_printf(...) do {} while (0) /* Finer-grained debug switches */ #define debug_printf_parse(...) do {} while (0) #define debug_print_tree(a, b) do {} while (0) #define debug_printf_exec(...) do {} while (0) #define debug_printf_jobs(...) do {} while (0) #define debug_printf_expand(...) do {} while (0) #define debug_printf_clean(...) do {} while (0) Comment out define debug_printf_exec: //#define debug_printf_exec(...) do {} while (0) and rebuild busybox. Now run it and type "ls". For me, it shows this: $ ls parse_stream_outer: run_list run_list entered : run_list_real with 1 members run_list_real start lvl 1 : rword=0 if_code=0 next_if_code=0 skip_more=12 : run_pipe_real with 1 members run_pipe_real start: single_fg=1 : pipe member 'ls' '(null)'... execing 'ls' AUTHORS TODO_config_nommu console-tools ipsvd runit Config.in applets coreutils libbb scripts INSTALL arch debianutils libpwdgrp selinux LICENSE archival docs loginutils shell Makefile busybox e2fsprogs miscutils sysklogd Makefile.custom busybox_ldscript editors modutils testsuite Makefile.flags busybox_old examples networking util-linux Makefile.help busybox_unstripped findutils procps README busybox_unstripped.map include ps1 TODO busybox_unstripped.out init ps2 run_pipe_real return -1 : checkjobs returned 0 : setting last_return_code=0 : rword=0 if_code=0 next_if_code=0 skip_more=12 run_list_real lvl 1 return 0 run_list return 0 $ What do you see? -- vda From dv at vollmann.ch Mon Jan 7 00:37:36 2008 From: dv at vollmann.ch (Detlef Vollmann) Date: Mon, 07 Jan 2008 09:37:36 +0100 Subject: do ... while(0) optimization problem References: <4780FC31.40D92E45@vollmann.ch> <200801061314.19491.vapier@gentoo.org> Message-ID: <4781E4D0.644C1687@vollmann.ch> Mike Frysinger wrote: > so fix your gcc ? the point of do { ... } while (0) is to provide proper > wrapping context that can be used anywhere that a single statement can. I know. I personally prefer the comma operator, is possible, as this gives you a true expression (like a function call that is mimicked by the macro expansion). > sane > gcc will expand all of the code within without the do/while part because it's > a nop. The preprocessor will expand always everything, and the optimizer might remove anything that it believes make no difference on the external behaviour. The problem here might actually be the PTR_TO_GLOBALS, as the compiler thinks that ptr_to_globals can't be changed anyway, so the assignment might be optimized away... > you could always compare the disassembly output, but considering how ancient > your gcc is, that sounds like a waste of time Point taken, but maybe the problem is not specific to this version of this compiler. Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ From alexander.griesser at lkh-vil.or.at Mon Jan 7 02:08:46 2008 From: alexander.griesser at lkh-vil.or.at (Alexander Griesser) Date: Mon, 07 Jan 2008 11:08:46 +0100 Subject: Strange problems with FEATURE_VI_8BIT Message-ID: <4781FA2E.1040503@lkh-vil.or.at> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks! I tried to use FEATURE_VI_8BIT in busybox 1.9.0 bus was unsuccessful so far. Even though this feature is enabled in my configuration, I can't enter german umlauts into vi. Having a small peak at the code in vi.c, I commented out all occurences of: c = '.'; which made it work again (at least I could input all german umlauts without problems). To find out a bit more about this problem, I wrote a little test program: - ----------------------------- 8< ------------------------ int main(int argc, char **argv) { unsigned int x; while(1) { x = getc(stdin); if(isprint(x)) { printf("%c is printable\n", x); } else { printf("%c is not printable\n", x); } } return 0; } - ----------------------------- 8< ------------------------ Needless to say, it always prints out the "is not printable" text for all umlauts I enter. Am I doing something wrong or is this a bug? ciao, - -- 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 iD8DBQFHgfou66HVD6KUm1oRAllVAJ926wqnCMavN3YnM0bFB3dFpscSJwCbBhH2 Ml5MLDlQ492VRV1gwaVxqxs= =3j4v -----END PGP SIGNATURE----- From vda.linux at googlemail.com Mon Jan 7 07:56:02 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 15:56:02 +0000 Subject: syslogd In-Reply-To: <597123.96732.qm@web62506.mail.re1.yahoo.com> References: <597123.96732.qm@web62506.mail.re1.yahoo.com> Message-ID: <200801071556.03086.vda.linux@googlemail.com> On Sunday 06 January 2008 12:42, Alex Landau wrote: > As a side effect of my problems with syslogd described below, I found a bug (return value from shmat() > checked for error incorrectly), which is fixed by the attached patch. > > I'm running on NOMMU and using busybox 1.7 (and checked the relevant changes in syslogd.c till trunk head - none seems to be related). > The problem itself: Once in a while (about once a week), syslogd crashes. I traced the point of the crash, > and it is in log_to_shmem() in the "memcpy(G.shbuf->data + old_tail, msg, k);" line (line no. 268 in trunk head). So, it is either a corrupted/wrong G.shbuf->data or wrong old_tail. old_tail is taken from G.shbuf->tail: old_tail = G.shbuf->tail; and G.shbuf->tail is modified only in two places: G.shbuf->tail = 0; -- obviously correct one and G.shbuf->tail = new_tail; Just for paranoid reasons, add debug printout directly after above line: if (new_tail < 0 || new_tail >= G.shbuf->size) bb_error_and_die("ERROR! new_tail:%d ...more debug data here...", new_tail, ...); G.shbuf->data case is even more simple: it should never change. So you may save it in another static variable and check whether it changed at the beginning of log_to_shmem(). These two checks should catch the bug in action. > The pointer (G.shbuf->data + old_tail) points to a bizarre place (very far from the shm area shown in /proc/pid/maps), and naturally trying to write there crashes syslog. I thought the problem happens due to the circular buffer overflowing, but running "logger" several times in order to fill the whole buffer didn't crash syslog, so this does not seem to be related. > > I didn't succeed in finding the cause of the crash (memory corruption? something overwriting G.shbuf?), and would appreciate any help. > > Oh, and how did I find the "shmat() return value" bug? If after syslogd crashes, I (or actually runsv) runs it again, it crashes at the memset in ipcsyslog_init() trying to write to 0xFFFFFFFF. Maybe shmat() failed due to the crash of the previous instance of syslogd, for which the kernel probably haven't released all resources (NOMMU, remember), maybe not... But shmget() succeeded and that's strange. Fix is applied to svn, thanks! -- vda From vda.linux at googlemail.com Mon Jan 7 08:03:15 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 16:03:15 +0000 Subject: I can't log in In-Reply-To: <300726.30993.qm@web15808.mail.cnb.yahoo.com> References: <300726.30993.qm@web15808.mail.cnb.yahoo.com> Message-ID: <200801071603.15208.vda.linux@googlemail.com> On Sunday 06 January 2008 08:15, zhuzhu wrote: > dear sir: > I built my own filesystems with busybox ,use nfs to boot,and copy "group passwd shadow"to /myrootfs/etc.but I can't login with my user name,when I type my login name,:zhu.I get" > Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart.",it enve didn't ask me for password.,thank you for your help. Which version of busybox do you use? Which architecture/device do you use it on? Can you post your .config? > best regards > zhudq > here is the infomation: > > Probing IDE interface ide0... > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 2048 buckets, 16Kbytes > TCP: Hash tables configured (established 16384 bind 32768) > eth0: Phy @ 0x0, type LXT971 (0x001378e2) > IP-Config: Gateway not on directly connected network. > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Looking up port of RPC 100003/2 on 10.212.43.54 > Looking up port of RPC 100005/1 on 10.212.43.54 > VFS: Mounyted root (nfs fesystem). ^^^^^^^^ > Foreeing unused kemory: 76k init ^^^^^^^^ ?? > init started: BusyBox v1.1.2 (2008.01.05-09:08+0000) multi-call binary > Starting pid 11, console /dev/console: '/etc/init.d/rcS' > Bummer, could not run '/etc/init.d/rcS': No such file or directory > Bummer, could not run '/etc/init.d/rcS': No such file or directory > Starting pid 12, console /dev/console: '/sbin/getty' > > icecube login: zju > Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart. > Starting pid 13, console /dev/console: '/sbin/getty' Yes, getty seems to die incorrectly. :( If you have, or can build strace, try to start just /bin/sh instead of getty, and then run "strace /sbin/getty ..... ...." from the shell prompt. > icecube login: root > Process '/sbin/getty 115200 ttyS0' (pid 13) exited. Scheduling it for restart. > Starting pid 14, console /dev/console: '/sbin/getty' -- vda From vda.linux at googlemail.com Mon Jan 7 08:13:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 16:13:28 +0000 Subject: ps and username size In-Reply-To: <0801061529260.10489@somehost> References: <0801052121440.17543@somehost> <4780E1D0.60EE8CDE@vollmann.ch> <0801061529260.10489@somehost> Message-ID: <200801071613.28432.vda.linux@googlemail.com> On Sunday 06 January 2008 14:35, Cristian Ionescu-Idbohrn wrote: > On Sun, 6 Jan 2008, Detlef Vollmann wrote: > > > + smart_ulltoa4( (u, buf5, " mgtpezy"); > > ^^ > > This line contains a type, leading to: > > procps/ps.c: In function `put_lu': > > procps/ps.c:193: warning: left-hand operand of comma expression has no effect > > procps/ps.c:193: warning: left-hand operand of comma expression has no effect > > procps/ps.c:193: parse error before ';' token > > Just noticed some indentation whitespace damage in procps/ps.c. > Attached patch gives an idea on which areas need reindenting. Both are fixed in svn now, thanks! -- vda From vda.linux at googlemail.com Mon Jan 7 08:15:14 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 16:15:14 +0000 Subject: [PATCH] coreutils tac (was: coreutils tac) In-Reply-To: <200801061031.07188.farmatito@tiscali.it> References: <1198572349.7769.2.camel@nc.nor.wtbts.org> <200801060628.47416.vda.linux@googlemail.com> <200801061031.07188.farmatito@tiscali.it> Message-ID: <200801071615.14174.vda.linux@googlemail.com> On Sunday 06 January 2008 09:31, Tito wrote: > On Sunday 06 January 2008 07:28:47 Denys Vlasenko wrote: > > On Wednesday 02 January 2008 15:23, Natanael Copa wrote: > > > Denys, whats the status on the tac patch? > > > > Version which does inversion in memory is appled to svn. > > It handles non terminated last line the same as coreutils, > > but mishandles NULs. > Hi, > Denis, did you forget svn add again? :-) Yes :(. Try now. > Why it mishandles NULs? > I thought that i've got it right in version 2 of my patch (attached): > > ??????????????/* Get line and add it to the start of the temp linked list. */ > ????????????????while ((line = xmalloc_fgets(f))) { > ????????????????????????if (temp_list && !last_char_is(temp_list->data, '\n')) > ????????????????????????????????/* Last line ended with '\0' so concatenate them. */ > ???????????????????????????????? temp_list->data = xasprintf("%s%s", temp_list->data, line); > ????????????????????????else > ????????????????????????????????llist_add_to(&temp_list, line);? > ????????????????} > > this was the test file i used (attached): > 055 056 057 000 057 056 055 010 > > result is: > > GNU tac > tac prova4 > 789987 > > busybox > ./busybox tac prova4 > 789987 It's visibly similar, but GNU tac preserves NUL, while above version eats it. -- vda From vda.linux at googlemail.com Mon Jan 7 08:17:00 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 16:17:00 +0000 Subject: do ... while(0) optimization problem In-Reply-To: <4780FC31.40D92E45@vollmann.ch> References: <4780FC31.40D92E45@vollmann.ch> Message-ID: <200801071617.00590.vda.linux@googlemail.com> On Sunday 06 January 2008 16:05, Detlef Vollmann wrote: > Hello, > > in util-linux/fdisk.c, the macro > > #define INIT_G() do { \ > PTR_TO_GLOBALS = xzalloc(sizeof(G)); \ > sector_size = DEFAULT_SECTOR_SIZE; \ > sector_offset = 1; \ > g_partitions = 4; \ > display_in_cyl_units = 1; \ > units_per_sector = 1; \ > } while (0) > > seems to get partly optimized away in my gcc (GCC) 3.2.2. > I get a segmentation fault and it turns out that ptr_to_globals is 0. > > Rewriting the macro to > > #define INIT_G() ( \ > PTR_TO_GLOBALS = xzalloc(sizeof(G)), \ > sector_size = DEFAULT_SECTOR_SIZE, \ > sector_offset = 1, \ > g_partitions = 4, \ > display_in_cyl_units = 1, \ > units_per_sector = 1) > > works fine... huh? Do make util-linux/fdisk.s with both versions and post them here please. -- vda From vda.linux at googlemail.com Mon Jan 7 08:36:46 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 16:36:46 +0000 Subject: ps and username size In-Reply-To: <0801061433450.10489@somehost> References: <0801052121440.17543@somehost> <200801060324.28126.vda.linux@googlemail.com> <0801061433450.10489@somehost> Message-ID: <200801071636.46683.vda.linux@googlemail.com> On Sunday 06 January 2008 14:16, Cristian Ionescu-Idbohrn wrote: > On Sun, 6 Jan 2008, Denys Vlasenko wrote: > > > > Thanks for the report. Using %-8.8s instead of %-8s fixes this. > > > > I am also fixing VSZ overflow with large VSZs. > > > > Will commit changes to svn in a minute. > > Thanks. > The attached patch properly adjusts the columns to the header and > immitates debian ps from procps-3.2.7-5. > > bb-ps (revision 20806) > > PID USER VSZ STAT COMMAND > 1 root 2080 S init [2] > 2 root 0 SW< [kthreadd] > 3 root 0 SW< [migration/0] > 4 root 0 SWN [ksoftirqd/0] > 5 root 0 SW< [watchdog/0] > 6 root 0 SW< [migration/1] > 7 root 0 SWN [ksoftirqd/1] > 8 root 0 SW< [watchdog/1] > 9 root 0 SW< [events/0] > # ps -A -o pid,user,vsz,stat,command | head > PID USER VSZ STAT COMMAND > 1 root 2080 Ss init [2] > 2 root 0 S< [kthreadd] > 3 root 0 S< [migration/0] > 4 root 0 SN [ksoftirqd/0] > 5 root 0 S< [watchdog/0] > 6 root 0 S< [migration/1] > 7 root 0 SN [ksoftirqd/1] > 8 root 0 S< [watchdog/1] > 9 root 0 S< [events/0] - len = printf("%5u %-8.8s %s %s ", + len = printf("%5u %-8.8s %6s %-4s ", p->pid, user, buf6, p->state); Re "%6s": buf6 is always 5 chars long. With this patch, you have at least two spaces between USER and VSZ. Not useful. Re "%-4s": Correct, p->state is always 3 chars. I will do it by adding a space: "%s ". > The current svn chops of long usernames to 8 chars. That may create > confusion if the output from ps is in any way used to identify process > owners. Users: > > 'longnameA' and 'longnameB' will both be displayed as 'longname'. > > Please consider replacing usernames longer than 8 chars with the > corresponding uids. That will make them unique in the ps list. Good idea. -- vda From vda.linux at googlemail.com Mon Jan 7 10:55:12 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 7 Jan 2008 18:55:12 +0000 Subject: Hush cant replace lash for my situation In-Reply-To: References: Message-ID: <200801071855.12760.vda.linux@googlemail.com> On Sunday 06 January 2008 22:03, Martinb_ARM_NOMMU_KISSDVD wrote: > I did build the toolchain but i used a script, i will try to learn to build > my own uclibc but if i look at the buildscript and all the patches the > developers have used then i think i will never be able to do this (but i > will try, and will bug you on a new thread if im stuck) > > > I did remove the -DBB_NOMMU (dont remember why i ever put it ther in the > first place) > Did Comment out define debug_printf_exec and recompile > run it and type "ls". For me, it shows this: > > =============================================== > /hdd/shell # ls > parse_stream_outer: run_list > run_list entered > : run_list_real with 1 members > run_list_real start lvl 1 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > : run_pipe_real with 1 members > run_pipe_real start: single_fg=1 > : pipe member 'ls' '(null)'... > run_pipe_real return -1 > : checkjobs returned 0 > : setting last_return_code=0 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > run_list_real lvl 1 return 0 > run_list return 0 > ================================================ It seems it never goes into if (!child->pid) {...} part below: Can you add debug_printf_exec() as shown wit '+' and test again? if (child->argv) debug_printf_exec(": pipe member '%s' '%s'...\n", child->argv[0], child->argv[1]); else debug_printf_exec(": pipe member with no argv\n"); /* pipes are inserted between pairs of commands */ if ((i + 1) < pi->num_progs) { pipe(pipefds); nextout = pipefds[1]; } else { nextout = 1; pipefds[0] = -1; } /* XXX test for failed fork()? */ #if BB_MMU child->pid = fork(); + debug_printf_exec(": vfork returned %d\n", child->pid); #else child->pid = vfork(); + debug_printf_exec(": fork returned %d\n", child->pid); #endif if (!child->pid) { /* child */ -- vda From michaelbertelson at yahoo.com Mon Jan 7 14:07:59 2008 From: michaelbertelson at yahoo.com (Michael Bertelson) Date: Mon, 7 Jan 2008 14:07:59 -0800 (PST) Subject: Boot issues with latest Busybox and Linux Kernel (GLIBC) Message-ID: <671731.20630.qm@web61111.mail.yahoo.com> I'm using some of the CLFS instructions to create a Busybox GLIBC Linux system with the 2.6.23.12 kernel. The system boots to the init.d scripts to find that it's devices are not there, then it shuts down. /dev/hda1 and /dev/null, as an example, it complains are not there, even though in the case of /dev/null, I manually created one. The startup scripts actually say they are to mount the /dev, /sys, etc. Is this the issue by chance? Do I need an initrd or something to mount those prior to the symlink /linuxrc -> busybox is run? I thought that was supposed to initialize the dev file system, even though I can find no documentation as to what the busybox linuxrc symlink does. Interestingly enough, it does appear that things like the eth interfaces are actually there, since it actually says it brought up the network interface in the startup script shortly before shutting the system down. Does anyone have any ideas for me to try? I feel really close to getting this working, but I am missing some information about how the whole boot process works. I did try even setting up an initrd from scratch to run a linuxrc that should even echo statements back to me, but it didn't seem to ever echo them even though the boot statements told me it saw the ext2 initrd. Odd. Thank you in advance --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080107/58487990/attachment.htm From martinb at zeelandnet.nl Mon Jan 7 14:34:41 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Mon, 7 Jan 2008 23:34:41 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <200801071855.12760.vda.linux@googlemail.com> Message-ID: did include the 2 lines and recompile output is: parse_stream_outer: run_list run_list entered : run_list_real with 1 members run_list_real start lvl 1 : rword=0 if_code=0 next_if_code=0 skip_more=12 : run_pipe_real with 1 members run_pipe_real start: single_fg=1 : pipe member 'ls' '(null)'... : vfork returned -1 run_pipe_real return -1 : checkjobs returned 0 : setting last_return_code=0 : rword=0 if_code=0 next_if_code=0 skip_more=12 run_list_real lvl 1 return 0 run_list return 0 You can give me more debug instructions if you want, i dont have the skills but i do have the time /martinb > ================================================ It seems it never goes into if (!child->pid) {...} part below: Can you add debug_printf_exec() as shown wit '+' and test again? if (child->argv) debug_printf_exec(": pipe member '%s' '%s'...\n", child->argv[0], child->argv[1]); else debug_printf_exec(": pipe member with no argv\n"); /* pipes are inserted between pairs of commands */ if ((i + 1) < pi->num_progs) { pipe(pipefds); nextout = pipefds[1]; } else { nextout = 1; pipefds[0] = -1; } /* XXX test for failed fork()? */ #if BB_MMU child->pid = fork(); + debug_printf_exec(": vfork returned %d\n", child->pid); #else child->pid = vfork(); + debug_printf_exec(": fork returned %d\n", child->pid); #endif if (!child->pid) { /* child */ -- vda From cristian.ionescu-idbohrn at axis.com Mon Jan 7 15:20:42 2008 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Tue, 8 Jan 2008 00:20:42 +0100 (CET) Subject: ps and username size In-Reply-To: <200801071636.46683.vda.linux@googlemail.com> References: <0801052121440.17543@somehost> <200801060324.28126.vda.linux@googlemail.com> <0801061433450.10489@somehost> <200801071636.46683.vda.linux@googlemail.com> Message-ID: <0801072353000.15986@somehost> On Mon, 7 Jan 2008, Denys Vlasenko wrote: > On Sunday 06 January 2008 14:16, Cristian Ionescu-Idbohrn wrote: > > - len = printf("%5u %-8.8s %s %s ", > + len = printf("%5u %-8.8s %6s %-4s ", > p->pid, user, buf6, p->state); > > Re "%6s": > buf6 is always 5 chars long. With this patch, you have at least > two spaces between USER and VSZ. Not useful. > > Re "%-4s": > Correct, p->state is always 3 chars. I will do it by adding > a space: "%s ". That's fine, but here are some STAT differencies I observed between bb v1.10.0.svn ps and ps from procps-3.2.7 on my debian sid box (see attached files and compare linewise). STAT is up to 4 chars on one process: ps-stat.lis:143: 14147 SLs+ pid 14147 is shown like this right now: PID USER VSZ STAT COMMAND 14147 root 145760 RLs+ /usr/bin/X11/X -dpi 100 -nolisten tcp ^^^^ I see something similar on another box (debian etch): PID USER VSZ STAT COMMAND 13171 root 2528 S > The current svn chops of long usernames to 8 chars. That may create > > confusion if the output from ps is in any way used to identify process > > owners. Users: > > > > 'longnameA' and 'longnameB' will both be displayed as 'longname'. > > > > Please consider replacing usernames longer than 8 chars with the > > corresponding uids. That will make them unique in the ps list. > > Good idea. Super. I made an attempt in a previous sent patch to do just that. It probably just passed unnoticed :( Cheers, -- Cristian -------------- next part -------------- PID STAT 1 S 2 SW< 3 SW< 4 SWN 5 SW< 6 SW< 7 SWN 8 SW< 9 SW< 10 SW< 11 SW< 30 SW< 31 SW< 32 SW< 33 SW< 132 SW< 158 SW< 159 SW< 160 SW< 648 SW< 649 SW< 771 SW< 772 SW< 773 SW< 844 SW< 845 SW< 1242 SW< 1810 SW< 1811 SW< 1998 S < 2436 SW< 2809 SW< 2815 SW< 2820 SW< 2828 SW< 2833 SW< 2838 SW< 2844 SW< 2849 SW< 2854 SW< 2888 SW< 2889 SW< 3540 S 3549 S 3775 S 3782 S 3795 S 3889 S 3905 S 3915 S 4001 S 4033 S 4042 S 4050 S 4056 S 4058 S 4063 S N 4064 S N 4079 S 4083 S 4123 S 4129 S N 4140 S 4142 S 4153 S 4167 S N 4169 S N 4183 S 4222 S 4223 S 4282 S 4326 SW 4327 SW< 4328 SW< 4329 SW< 4330 SW 4331 SW 4332 SW 4333 SW 4334 SW 4335 SW 4336 SW 4337 SW 4341 S 4367 S 4381 S 4388 S 4395 S 4402 S 4404 S 4477 S 4486 S 4504 S 4507 S 4510 S 4514 S 4518 S 4522 S 4531 S 4542 S 4551 S 4558 S 4578 S 4591 S 4599 S 4639 S 4643 S 4726 S 4740 S 4794 S 4815 S 4816 S 4839 S 4847 S 4849 S 4901 S 4911 S 4938 S 4945 S 4976 S 5128 S 5129 S 5130 S 5131 S 5132 S 5134 S 5234 S 5654 S 6525 S 6526 S 6527 S 6528 S 6529 S 6530 S 6849 S 6858 S 10324 S < 13689 S 13732 S 14129 S 14146 S 14147 S 14152 S 14191 S 14204 S 14205 S 14207 S 14213 S 14219 S 14220 S 14229 S 14230 S 14231 S 14232 S 14233 S 14234 S 14235 S 14236 S 14237 S 14238 S 14239 S 14240 S 14241 S 14242 S 14243 S 14244 S 14245 S 14246 S 14247 S 14248 S 14249 S 14250 S 14251 S 14252 S 14253 S 14255 S 14256 S 14257 S 14258 S 14259 S 14269 S 14270 S 14271 S 14272 S 14273 S 14274 S 14275 S 14278 S 14285 S 14286 S 14287 S 14288 S 14289 S 14290 S 14291 S 14340 S 14388 S 14443 S 14459 S 14460 S 14461 S 14463 S 14464 S 14479 S 14518 S 14519 S 14520 S 15953 S 15986 S 16358 SW 16925 SW 17112 S 17113 S 17464 S 17469 S 18594 S N 18596 S N 22048 S N 26211 S -------------- next part -------------- PID STAT 1 Ss 2 S< 3 S< 4 SN 5 S< 6 S< 7 SN 8 S< 9 S< 10 S< 11 S< 30 S< 31 S< 32 S< 33 S< 132 S< 158 S< 159 S< 160 S< 648 S< 649 S< 771 S< 772 S< 773 S< 844 S< 845 S< 1242 S< 1810 S< 1811 S< 1998 S References: Message-ID: <200801080005.10615.vda.linux@googlemail.com> On Monday 07 January 2008 22:34, Martinb_ARM_NOMMU_KISSDVD wrote: > did include the 2 lines and recompile > output is: > > parse_stream_outer: run_list > run_list entered > : run_list_real with 1 members > run_list_real start lvl 1 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > : run_pipe_real with 1 members > run_pipe_real start: single_fg=1 > : pipe member 'ls' '(null)'... > : vfork returned -1 > run_pipe_real return -1 > : checkjobs returned 0 > : setting last_return_code=0 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > run_list_real lvl 1 return 0 > run_list return 0 Can you run "make ...all usual make params... shell/hush.s" and send me resulting hush.s? -- vda From martinb at zeelandnet.nl Mon Jan 7 16:25:31 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Tue, 8 Jan 2008 01:25:31 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <200801080005.10615.vda.linux@googlemail.com> Message-ID: I did "make ARCH=arm CROSS_COMPILE=arm-uclinux-elf- EXTRA_CFLAGS="-D__uClinux__ -DSKIP_STRIP=y" LDFLAGS="-Wl,-elf2flt" shell/hush.s" I did attach the hush.s /martinb -----Oorspronkelijk bericht----- Van: Denys Vlasenko [mailto:vda.linux at googlemail.com] Verzonden: dinsdag 8 januari 2008 1:05 Aan: Martinb_ARM_NOMMU_KISSDVD CC: busybox at busybox.net Onderwerp: Re: Hush cant replace lash for my situation On Monday 07 January 2008 22:34, Martinb_ARM_NOMMU_KISSDVD wrote: > did include the 2 lines and recompile > output is: > > parse_stream_outer: run_list > run_list entered > : run_list_real with 1 members > run_list_real start lvl 1 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > : run_pipe_real with 1 members > run_pipe_real start: single_fg=1 > : pipe member 'ls' '(null)'... > : vfork returned -1 > run_pipe_real return -1 > : checkjobs returned 0 > : setting last_return_code=0 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > run_list_real lvl 1 return 0 > run_list return 0 Can you run "make ...all usual make params... shell/hush.s" and send me resulting hush.s? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: hush.s.gz Type: application/x-gzip Size: 20819 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20080108/e56dbe55/attachment-0001.bin From emaildq at yahoo.com.cn Mon Jan 7 18:18:59 2008 From: emaildq at yahoo.com.cn (zhuzhu) Date: Tue, 8 Jan 2008 10:18:59 +0800 (CST) Subject: I can't log in Message-ID: <276138.83600.qm@web15804.mail.cnb.yahoo.com> To Denys Vlasenko: The version of my busybox is 1.4.2,and my board is mpc5200(lite5200) ppc arch. the files in myrootfs /etc/ (inittab content?? ::sysinit:/etc/init.d/rcS ::respawn:/sbin/getty 115200 ttyS0 ::restart:/sbin/init ::shutdown:/bin/umount ?Ca ?Cr $ mkdir init.d $ vi init.d/rcS (rcS content?? ????/bin/sh /bin/mount -a $ vi fstab (fstab content) # /etc/fstab # device directory type options # none /proc proc defaults busides I copy ""group passwd shadow"from my radhat9.0 /etc to myrootfs/etc. so I think I use my username "zhu" to login,when I input my usename and hit enter, I got"Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart." Thank you for your help,here is the information Probing IDE interface ide0... NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 32768) eth0: Phy @ 0x0, type LXT971 (0x001378e2) IP-Config: Gateway not on directly connected network. NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 100003/2 on 10.212.43.54 Looking up port of RPC 100005/1 on 10.212.43.54 VFS: Mounyted root (nfs fesystem). Foreeing unused kemory: 76k init init started: BusyBox v1.1.2 (2008.01.05-09:08+0000) multi-call binary Starting pid 11, console /dev/console: '/etc/init.d/rcS' Bummer, could not run '/etc/init.d/rcS': No such file or directory Bummer, could not run '/etc/init.d/rcS': No such file or directory Starting pid 12, console /dev/console: '/sbin/getty' icecube login: zhu Process '/sbin/getty 115200 ttyS0' (pid 12) exited. Scheduling it for restart. Starting pid 13, console /dev/console: '/sbin/getty' icecube login: root Process '/sbin/getty 115200 ttyS0' (pid 13) exited. Scheduling it for restart. Starting pid 14, console /dev/console: '/sbin/getty' --------------------------------- ?????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20080108/e1bee897/attachment.htm From vapier at gentoo.org Mon Jan 7 22:04:05 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Tue, 8 Jan 2008 01:04:05 -0500 Subject: Boot issues with latest Busybox and Linux Kernel (GLIBC) In-Reply-To: <671731.20630.qm@web61111.mail.yahoo.com> References: <671731.20630.qm@web61111.mail.yahoo.com> Message-ID: <200801080104.06038.vapier@gentoo.org> please fix your mailer to properly line wrap your messages On Monday 07 January 2008, Michael Bertelson wrote: > I'm using some of the CLFS instructions to create a Busybox GLIBC Linux > system with the 2.6.23.12 kernel. The system boots to the init.d scripts > to find that it's devices are not there, then it shuts down. /dev/hda1 and > /dev/null, as an example, it complains are not there, even though in the > case of /dev/null, I manually created one. > > The startup scripts actually say they are to mount the /dev, /sys, etc. Is > this the issue by chance? Do I need an initrd or something to mount those > prior to the symlink /linuxrc -> busybox is run? I thought that was > supposed to initialize the dev file system, even though I can find no > documentation as to what the busybox linuxrc symlink does. > > Interestingly enough, it does appear that things like the eth interfaces > are actually there, since it actually says it brought up the network > interface in the startup script shortly before shutting the system down. > > Does anyone have any ideas for me to try? I feel really close to getting > this working, but I am missing some information about how the whole boot > process works. I did try even setting up an initrd from scratch to run a > linuxrc that should even echo statements back to me, but it didn't seem to > ever echo them even though the boot statements told me it saw the ext2 > initrd. Odd. this isnt a busybox problem ... please follow up with the LFS/CLFS projects in the future. if you're using mdev from busybox, please review the docs/mdev.txt document. this covers everything you're asking after. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/busybox/attachments/20080108/6e177cbf/attachment.pgp From landau_alex at yahoo.com Mon Jan 7 22:33:14 2008 From: landau_alex at yahoo.com (Alex Landau) Date: Mon, 7 Jan 2008 22:33:14 -0800 (PST) Subject: Fw: Hush cant replace lash for my situation Message-ID: <633594.58378.qm@web62508.mail.re1.yahoo.com> Denys, It prints vfork(), but actually executes fork() (a typo in your patch below), so I'd say busybox does not recognize that this is a NOMMU system. Alex ----- Forwarded Message ---- > From: Martinb_ARM_NOMMU_KISSDVD > To: Denys Vlasenko > Cc: busybox at busybox.net > Sent: Tuesday, January 8, 2008 12:34:41 AM > Subject: RE: Hush cant replace lash for my situation > > did include the 2 lines and recompile > output is: > > parse_stream_outer: run_list > run_list entered > : run_list_real with 1 members > run_list_real start lvl 1 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > : run_pipe_real with 1 members > run_pipe_real start: single_fg=1 > : pipe member 'ls' '(null)'... > : vfork returned -1 > run_pipe_real return -1 > : checkjobs returned 0 > : setting last_return_code=0 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > run_list_real lvl 1 return 0 > run_list return 0 > > You can give me more debug instructions if you want, i dont have > the > skills > but i do have the time > > /martinb > > > > ================================================ > > It seems it never goes into if (!child->pid) {...} part below: > Can you add debug_printf_exec() as shown wit '+' and test again? > > if (child->argv) > debug_printf_exec(": pipe member > '%s' > '%s'...\n", > child->argv[0], child->argv[1]); > else > debug_printf_exec(": pipe member with > no > argv\n"); > > /* pipes are inserted between pairs of commands */ > if ((i + 1) < pi->num_progs) { > pipe(pipefds); > nextout = pipefds[1]; > } else { > nextout = 1; > pipefds[0] = -1; > } > > /* XXX test for failed fork()? */ > #if BB_MMU > child->pid = fork(); > + debug_printf_exec(": vfork returned %d\n", child->pid); > #else > child->pid = vfork(); > + debug_printf_exec(": fork returned %d\n", child->pid); > #endif > if (!child->pid) { /* child */ > > -- > vda > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From martinb at zeelandnet.nl Mon Jan 7 23:54:06 2008 From: martinb at zeelandnet.nl (Martinb_ARM_NOMMU_KISSDVD) Date: Tue, 8 Jan 2008 08:54:06 +0100 Subject: Hush cant replace lash for my situation In-Reply-To: <633594.58378.qm@web62508.mail.re1.yahoo.com> Message-ID: hmm, you never going to believe this but when I do replace all the forks with a vfork (3 times) then it does run So i guess Alex is correct I did not yet made the changes line by line to find out which one of the 3 forks is the problem but I will as soon I'm back from work /martinb -----Oorspronkelijk bericht----- Van: Alex Landau [mailto:landau_alex at yahoo.com] Verzonden: dinsdag 8 januari 2008 7:33 Aan: Denys Vlasenko CC: busybox at busybox.net; Martinb_ARM_NOMMU_KISSDVD Onderwerp: Fw: Hush cant replace lash for my situation Denys, It prints vfork(), but actually executes fork() (a typo in your patch below), so I'd say busybox does not recognize that this is a NOMMU system. Alex ----- Forwarded Message ---- > From: Martinb_ARM_NOMMU_KISSDVD > To: Denys Vlasenko > Cc: busybox at busybox.net > Sent: Tuesday, January 8, 2008 12:34:41 AM > Subject: RE: Hush cant replace lash for my situation > > did include the 2 lines and recompile > output is: > > parse_stream_outer: run_list > run_list entered > : run_list_real with 1 members > run_list_real start lvl 1 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > : run_pipe_real with 1 members > run_pipe_real start: single_fg=1 > : pipe member 'ls' '(null)'... > : vfork returned -1 > run_pipe_real return -1 > : checkjobs returned 0 > : setting last_return_code=0 > : rword=0 if_code=0 next_if_code=0 skip_more=12 > run_list_real lvl 1 return 0 > run_list return 0 > > You can give me more debug instructions if you want, i dont have > the > skills > but i do have the time > > /martinb > > > > ================================================ > > It seems it never goes into if (!child->pid) {...} part below: > Can you add debug_printf_exec() as shown wit '+' and test again? > > if (child->argv) > debug_printf_exec(": pipe member > '%s' > '%s'...\n", > child->argv[0], child->argv[1]); > else > debug_printf_exec(": pipe member with > no > argv\n"); > > /* pipes are inserted between pairs of commands */ > if ((i + 1) < pi->num_progs) { > pipe(pipefds); > nextout = pipefds[1]; > } else { > nextout = 1; > pipefds[0] = -1; > } > > /* XXX test for failed fork()? */ > #if BB_MMU > child->pid = fork(); > + debug_printf_exec(": vfork returned %d\n", child->pid); > #else > child->pid = vfork(); > + debug_printf_exec(": fork returned %d\n", child->pid); > #endif > if (!child->pid) { /* child */ > > -- > vda > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > ______________________________________________________________________ ______________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From vda.linux at googlemail.com Tue Jan 8 04:29:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Tue, 8 Jan 2008 12:29:54 +0000 Subject: Boot issues with latest Busybox and Linux Kernel (GLIBC) In-Reply-To: <671731.20630.qm@web61111.mail.yahoo.com> References: <671731.20630.qm@web61111.mail.yahoo.com> Message-ID: <200801081229.54279.vda.linux@googlemail.com> On Monday 07 January 2008 22:07, Michael Bertelson wrote: > I'm using some of the CLFS instructions to create a Busybox GLIBC Linux system with the 2.6.23.12 kernel. The system boots to the init.d scripts to find that it's devices are not there, then it shuts down. /dev/hda1 and /dev/null, as an example, it complains are not there, even though in the case of /dev/null, I manually created one. I don't know what CLFS is. > The startup scripts actually say they are to mount the /dev, /sys, etc. Is this the issue by chance? Do I need an initrd or something to mount those prior to the symlink /linuxrc -> busybox is run? I thought th