# Using busybox as /bin/sh

## steveL

I switched my /bin/sh symlink to point to /bin/bb instead of /bin/bash a few months ago. I thought the patches I needed would be in openrc soon enough, as I was told someone would be trying it. Anyhow, thought I'd share them since I was recently emailed by someone off-list who found he was having problems, though in his case it was mysql which I don't use.

They're available in the bugzilla for people using stable openrc-11.8 as I am. Thought I'd start the topic also to discuss other changes that might be needed, eg for mysql as it's required for KDE unless you disable semantic-craptop, which many won't want to do as it means you lose Kmail.

It really does speed up your machine: I was amazed at the difference in bootup time, which wasn't my aim. I'd first tried using bb under mutt when switching from KMail, and then as SHELL = /bin/bb in makefiles, where it's also much quicker. So I thought I'd see if it helped my machine: and it does, it really really does. :-)

So, if you're interested, try it out. If not, no probs.

Have a good one :)

----------

## SlashBeast

Hi,

I am using app-shells/ash-bb (ash-only busybox build, faster than full busybox) as /bin/sh for quite some time and I choosen to patch openrc to use /bin/bash instead (before I used dash as /bin/sh) as there is still much bashism here and there.

So far my very only problem with ash as /bin/sh was glibc-2.17 which fails to be compiled with. Reported upstream.

----------

## steveL

 *SlashBeast wrote:*   

> I am using app-shells/ash-bb (ash-only busybox build, faster than full busybox) as /bin/sh for quite some time and I choosen to patch openrc to use /bin/bash instead (before I used dash as /bin/sh) as there is still much bashism here and there

 

Interesting. Wrt bashisms, there might well have been when you first switched, since baselayout-1 used bash, and openrc initscripts were originally from there. It's much better now though, as there is a commitment to POSIX sh.

As for speed, what I like about full busybox is that it runs a lot of the stuff that initscripts (and sh scripts in general) execute, as builtins. 9 times out of 10 it doesn't even need to fork; only in the cases where something is complex and even then it usually execs itself, falling back to the external only when it doesn't implement something. (I've seen this with ed.) Does ash-bb still incorporate grep and sed for example? (The one I use most elsewhere is awk, but grep and sed are really common in this domain.)

 *Quote:*   

> So far my very only problem with ash as /bin/sh was glibc-2.17 which fails to be compiled with. Reported upstream.

 

Heh, I'm still on 2.15.

----------

## steveL

Others have brought up in another thread that there are issues with some initscripts; mv mentions things using start-stop-daemon. I have only run into the ones I've patched, but then I don't run many services by design, and don't administer any network machines.

The person having an issue with mysql, also brought up ssd with another initscript redis, with the  -d (--chdir) option. AFAIK ssd is in C, so the issue is more likely to do with a script labelled /bin/sh that should be using /bin/bash somewhere. When he's back online we'll see what's getting run.

And really that's all any of us can do: if we want to customise our systems, we might have to patch and file bugs for unportable scripts masquerading as portable ones, or assuming built-in options that are not POSIX, or Linux-specific ones which busybox doesn't support. That's what this thread, and #openrc in the case of non-POSIX-compatible scripts, are for :-)

----------

## khayyam

steveL ...

Thought I'd give this a try, didn't use any of your patches just one or two manual edits to swap, and the start-stop-command alias. I was able to boot with just one or two small issues. For some reason swap doesn't seem to get activated (even with the '-e' switch removed) even though the rcscript returns success, swapfiles (which I have no need of, but was none the less in the runlevel) then had issues subsequently:

```
 * Activating additional swap space ...

swapon: /dev/mapper/vg_1-lv_swap: Device or resource busy
```

I assume 'swap' may still be running swapon and the subsequent 'swapon -a' causes the process to fail .. really couldn't say, and didn't invest much time on trying to figure out the exact reason.

Also, asound seems to have issues, with dash mdev has no problem loading the snd modules, but with bb I need to have them explicitly loaded at sysinit otherwise the following occurs:

```
 * Storing ALSA Mixer Levels ...

alsactl: save_state:1580: No soundcards found...
```

All of this is not particularly problematic, and I could work arround, however with bb set as /bin/sh manpages nolonger display colour, the escape characters are displayed. I have various LESS_TERMCAP_* variables set for bold, underline, etc, and as groff is running 'sh -c ... echo' bb has some issue with it.

All that aside, I really didn't notice any speed improvement above dash, infact I'm inclinded to think dash was a little faster (at boot time) as bb seemed to hang (very briefly) at points (of course, I could have blinked ... so, no objective evalutation given).

BTW, the patches/files you provided were all CRLF line terminated, and though I think patch will handle that you might want to fix (anyhow, thought I would of inform you).

best ... khay

----------

## mv

 *khayyam wrote:*   

> however with bb set as /bin/sh manpages nolonger display colour, the escape characters are displayed. I have various LESS_TERMCAP_* variables

 

I cannot confirm that with  */etc/man.conf wrote:*   

> PAGER /usr/bin/less -+F -LiMXsR --shift 5

  However it was necessary to export GROFF_NO_SGR= since otherwise sequences occur in the manpage which cannot be detected by the LESS_TERMCAP_{mb,md,us,so,me,ue,se} values - I do not really understand what is going on here - but that is not related with a bash/bb/dash change. Oh, it may be a difference that these LESS_TERMCAP variables in my case contain the "true" (binary) escape symbol (i.e. $(printf '\033') instead of '\e' or something similar).

----------

## khayyam

 *mv wrote:*   

>  *khayyam wrote:*   however with bb set as /bin/sh manpages nolonger display colour, the escape characters are displayed. I have various LESS_TERMCAP_* variables 
> 
> I cannot confirm that

 

mv ... it was indeed the PAGER variable, in my case it was set to 'less' and so bb was using its builtin. Setting it to the full path fixes it.

thanks & best ... khay

----------

## khayyam

steveL, et al ...

after some further messing arround and edits to my net.* and local.d scripts everything seems to be working with bb. I still have to explicitly load any modules prior to anything that may require them subsequently, but it works.

The issue with swap seemed to have been caused by having both swap and swapfile in boot, the latter seemed to negate the former for some odd reason.

I'm not really seeing any noticable increase in speed at boot, at least compared to dash, perhaps there isn't so much forking going on, but its not particularly important. I'll be switching back and forth between dash and bb on reboots and try to get a sense of each.

best ... khay

----------

## steveL

 *khayyam wrote:*   

> Thought I'd give this a try, didn't use any of your patches just one or two manual edits to swap, and the start-stop-command alias. I was able to boot with just one or two small issues. For some reason swap doesn't seem to get activated (even with the '-e' switch removed) even though the rcscript returns success, swapfiles (which I have no need of, but was none the less in the runlevel) then had issues subsequently

 

Ah good catch, khayyam, thanks. My mistake: I've been running a patched swapfiles, but similarly to consolefont, I didn't save off the .orig first. (I've never been able to get --noconfmem to bring back the original initscripts either.) So I simply missed that it had been patched at all. I cleaned it up, and just rebooted to check the cleanup didn't break anything. This is /etc/init.d/swapfiles:

```
#!/sbin/runscript

# Copyright (c) 2007-2009 Roy Marples <roy@marples.name>

# busybox patch: Steven J Long, 2012

# Released under the 2-clause BSD license.

depend()

{

   need localmount

   keyword -jail -openvz -prefix -vserver -lxc

}

start()

{

   ebegin "Activating additional swap space"

   case $RC_UNAME in

      NetBSD|OpenBSD) swapctl -A -t noblk

   ;;   *) if [ swapon = "$(command -v swapon)" ]; then

            swapon -a 2>&1

         else swapon -a

         fi

   esac >/dev/null

   eend 0 # If swapon has nothing todo it errors, so always return 0

}

stop()

{

   ebegin "Deactivating additional swap space"

   # Try to unmount all tmpfs filesystems not in use, else a deadlock may

   # occur. As $RC_SVCDIR may also be tmpfs we cd to it to lock it

   # fixme: Do we need this here since we are only unmounting swap files

   # and loopback swap?

   cd "$RC_SVCDIR"

   if [ Linux = "$RC_UNAME" ]; then

      if [ umount = "$(command -v umount)" ]; then

         [ -x /sbin/umount ] && /sbin/umount -a -t tmpfs

      else umount -a -t tmpfs

      fi 2>/dev/null

      if [ -e /proc/swaps ]; then

         local filename type rest

         while read -r filename type rest; do

            case $type in

               file) swapoff $filename; continue

            esac

            case $filename in

               /dev/loop*) swapoff $filename

            esac

         done < /proc/swaps >/dev/null

      fi

   else umount -a -t tmpfs 2>/dev/null

   fi   

   eend 0

}

```

Not sure about modules: I have sound card stuff builtin since I'm not using anything fancy. Isn't that something you'd sort out with the modules initscript and /etc/modprobe.d?

I had the issue with manpage display as well, but only in console login, and when using bb directly in terminal (bash is still my login shell.) I'll try the playing with PAGER as well, thanks for that mv.

I have noticed that some manpages aren't found, though that was a while back, and I'm not sure if I fixed it, or something just fixed itself as software got updated, as I haven't noticed that for a while. I'll poke about and see in the next few days.

 *Quote:*   

> All that aside, I really didn't notice any speed improvement above dash, infact I'm inclinded to think dash was a little faster (at boot time) as bb seemed to hang (very briefly) at points (of course, I could have blinked ... so, no objective evalutation given).

 

Yeah, I wouldn't expect a noticeable difference against another minimal shell; just against bash, which I wasn't even looking for when I switched. The whole thing was more of an experiment since I'd noticed the difference when playing with mutt, and then in makefiles.

The only script I notice pausing is udev waiting for things to settle, though in general there's always a couple of minor pauses, as things wait for hardware, but that used to happen under bash. I couldn't even tell you what: just that I don't expect bootup to be a smooth continuous process. But if you're switching back and forth to compare, it would be great to see what anomalies you find.

 *Quote:*   

> BTW, the patches/files you provided were all CRLF line terminated, and though I think patch will handle that you might want to fix (anyhow, thought I would of inform you).

 

Ah thanks: I just pasted the files into the form window in the browser, and HTTP uses CRLF line-endings (though you'd think the file would be converted since we're all on Unix, I guess it's not something software would do by default.) Next time I'll load them from a file.

----------

## khayyam

 *steveL wrote:*   

> I've been running a patched swapfiles, but similarly to consolefont, I didn't save off the .orig first.

 

steveL ... ok, well, I didn't need to have it in the runlevel and so ended up removing it, but for the sake of getting patches and what-have-you in one place I made a diff (after merging the changes into a non-tabexpanded copy of the original). The patch can be found here. I didn't test it at all, which is why I didn't add it to the bug, but the original can be found here if you wanted to do so.

 *steveL wrote:*   

> Not sure about modules: I have sound card stuff builtin since I'm not using anything fancy. Isn't that something you'd sort out with the modules initscript and /etc/modprobe.d?

 

yes, but my thought at the time was that if dash handled it then there was obviously some issue with busybox/ash.

 *steveL wrote:*   

> I have noticed that some manpages aren't found, though that was a while back, and I'm not sure if I fixed it, or something just fixed itself as software got updated, as I haven't noticed that for a while. I'll poke about and see in the next few days.

 

hmmm, can't say that's something I noticed, MANPATH would be something your interactive shell has set and so not something that /bin/sh would likely need, its basically just called to '-c' a subshell.

 *steveL wrote:*   

> The only script I notice pausing is udev waiting for things to settle, though in general there's always a couple of minor pauses, as things wait for hardware, but that used to happen under bash. I couldn't even tell you what: just that I don't expect bootup to be a smooth continuous process. But if you're switching back and forth to compare, it would be great to see what anomalies you find.

 

ok, will do, but I generally hibernate rather than shutdown so those "days" are more likely "weeks" :)

I have mdev in place of udev, and the effect I noticed I don't see with dash which is why I had the impression dash was faster (though, only very minimally). So, yeah, there isn't going to be much in it, but its not the speed I really care about, I plan to build some uclibc images for rehabbed eeepc's (to be used as point-to-point wireless routers) so I want to keep the images as small and light as possible, and I'll want to have busybox in place of bash.

best ... khay

----------

## steveL

 *khayyam wrote:*   

> I didn't need to have it in the runlevel and so ended up removing it, but for the sake of getting patches and what-have-you in one place I made a diff (after merging the changes into a non-tabexpanded copy of the original). The patch can be found here. I didn't test it at all, which is why I didn't add it to the bug, but the original can be found here if you wanted to do so.

 

Ah thanks khayyam, that looks good. I use tabs since the shell will read them more quickly (and I'm old-fashioned;) Looks like what will happen is that people will be advised to turn off applets in busybox config, and hopefully the options will be added to busybox soon. s-s-d seems like a big ask, though since it has a lot of options in openrc. Personally, if it were my scripts I'd keep the alias for that, since it's actually rc -a which we install, and we want to be certain to run the right thing, whatever situation we might be in.

The others I agree, just turning them off is enough (and ofc that does fix s-s-d under busybox since it's no longer there.) It just makes me uncomfortable since I've been schooled to make scripts portable, and in this context a bit of shell isn't much, and can be kept to pure shell easily enough. (It would mean people switching to try it out, could do so out of the box.) Still I guess it's a niche thing, and certainly in the embedded world it's easy enough to stipulate a recent busybox. Encouraging people to slim down their busybox is also a good thing.

Anyhow here's the README.busybox:

```
Using Busybox as your Default Shell

-----------------------------------

If you have/bin/sh linked to busybox, you need to be aware of several

incompatibilities between busybox's applets and the standalone

counterparts. Since it is possible to configure busybox to not include

these applets or to prefer the standalone counterparts, OpenRC does not

attempt to support the busybox applets.

All of these apply to busybox 1.20.2, which is the current version of

busybox as of this writing.

1. The start-stop-daemon applet is not compatible with start-stop-daemon

in OpenRC. Please make sure CONFIG_START_STOP_DAEMON is not set to y in

the configuration file you use to build busybox.

2. The -O option for the mount applet does not support the [no]_netdev

options from util-linux for handling network file systems.

3. The umount applet does not support the -O option from util-linux.

4. The swapon applet does not support the -e option from util-linux.

5. the setfont applet does not support the -u option from kbd.

There is work to get most of these supported by busybox, so this file

will be updated as things change.
```

 *Quote:*   

> yes, but my thought at the time was that if dash handled (modules) then there was obviously some issue with busybox/ash.

 

Yeah true. See what happens once you've slimmed down the config.

 *Quote:*   

> can't say that's something I noticed, MANPATH would be something your interactive shell has set and so not something that /bin/sh would likely need, its basically just called to '-c' a subshell.

 

Yeah, wrong description sorry. man -k printf gives unrecognised option, even in bash.

I'm beginning to see why busybox without the applets is appealing ;) I'd just like to keep sed, awk and grep at least.

 *Quote:*   

> I have mdev in place of udev, and the effect I noticed I don't see with dash which is why I had the impression dash was faster (though, only very minimally). So, yeah, there isn't going to be much in it, but its not the speed I really care about, I plan to build some uclibc images for rehabbed eeepc's (to be used as point-to-point wireless routers) so I want to keep the images as small and light as possible, and I'll want to have busybox in place of bash.

 

Yeah: I'd take a look at mirsh in combination with klibc as well: the discussion I mentioned in #ed was with its author, and he recommended looking at klibc (as well as musl, or uclibc..)

Kind regards,

steveL

----------

## khayyam

 *steveL wrote:*   

> Ah thanks khayyam, that looks good. I use tabs since the shell will read them more quickly (and I'm old-fashioned;)

 

SteveL ... I'd ment that I didn't copy-paste the version posted as all the tabs had been converted to spaces. So, the patch has proper tabs as is expected by gentoo coding standards.

 *steveL wrote:*   

> Looks like what will happen is that people will be advised to turn off applets in busybox config, and hopefully the options will be added to busybox soon. s-s-d seems like a big ask, though since it has a lot of options in openrc. Personally, if it were my scripts I'd keep the alias for that, since it's actually rc -a which we install, and we want to be certain to run the right thing, whatever situation we might be in.

 

I see ... perhaps slashbeasts ash-bb could be used if 'inherit savedconfig' was added.

 *steveL wrote:*   

> The others I agree, just turning them off is enough (and ofc that does fix s-s-d under busybox since it's no longer there.) It just makes me uncomfortable since I've been schooled to make scripts portable, and in this context a bit of shell isn't much, and can be kept to pure shell easily enough. (It would mean people switching to try it out, could do so out of the box.) Still I guess it's a niche thing, and certainly in the embedded world it's easy enough to stipulate a recent busybox. Encouraging people to slim down their busybox is also a good thing.

 

Ideally it should work without any modifications required but I can see why they might be hesitant to go that route, with bb you just can't be sure that every awk oneliner, or what-have-you, is going to work as expected. 

 *steveL wrote:*   

> Anyhow here's the README.busybox:

 

heh ... took me a little while to figure where I should be looking for this as I couldn't see it in my local git, and after a pull, bingo. I imagine that list isn't exhaustive as I'm inclined to think that modprobe has some deficiencies, and there are no doubt other things which will need ironing out.

 *steveL wrote:*   

> I'm beginning to see why busybox without the applets is appealing ;) I'd just like to keep sed, awk and grep at least.

 

check out the ash-bb::foo-overlay (slashbeasts overlay)

 *steveL wrote:*   

> Yeah: I'd take a look at mirsh in combination with klibc as well: the discussion I mentioned in #ed was with its author, and he recommended looking at klibc (as well as musl, or uclibc..)

 

The thing is gentoo already has experimental stage3's built with uclibc so it may save some time. I've read a little about musl but it seems that this may be entering unknown territory, if it was a shoe in I'm sure Aboriginal Linux would be using it already. There is a distribution, sabotage, using it exclusively but from the source tree it looks like there are various patches needed and so it would take some work to have this work with gentoo (at least, I assume).

best ... khay

----------

## steveL

 *khayyam wrote:*   

> Ideally it should work without any modifications required but I can see why they might be hesitant to go that route, with bb you just can't be sure that every awk oneliner, or what-have-you, is going to work as expected.

 

I've had no issue at all with awk. I test that it works in my configure scripts, and I've never had an issue with busybox, using POSIX character classes, and testing for variables in END.

I've seen strange errors from ed in terminal, but not in script, which is what makes me think it deals with those (ie unimplemented parts of the spec) differently during script execution, calling out to the external in PATH.

 *Quote:*   

> I imagine that list isn't exhaustive as I'm inclined to think that modprobe has some deficiencies, and there are no doubt other things which will need ironing out.

 

Yeah. Your input to the bug, which is now a tracker, will be valuable.

 *Quote:*   

>  *steveL wrote:*   I'm beginning to see why busybox without the applets is appealing ;) I'd just like to keep sed, awk and grep at least. 
> 
> (perhaps slashbeasts ash-bb could be used if 'inherit savedconfig' was added.)
> 
> check out the ash-bb::foo-overlay (slashbeasts overlay)

 

busybox already has a savedconfig USE flag: I just haven't looked into configuring it, since I read the docs a few months ago. It's come up now, so I will at some point. Like you, I'd rather things just worked without modification, in the main, but I think it's reasonable enough to encourage people to slim down their busybox, if they are using it as sh.

It would definitely be worth having a selection of sample configs for people to look at and compare, perhaps on the wiki.

 *Quote:*   

>  *steveL wrote:*   Yeah: I'd take a look at mirsh in combination with klibc as well: the discussion I mentioned in #ed was with its author, and he recommended looking at klibc (as well as musl, or uclibc..) 
> 
> The thing is gentoo already has experimental stage3's built with uclibc so it may save some time. I've read a little about musl

 

I was more intrigued by his recommendation of klibc than anything; he said it was designed for initramfs usage, so is very lightweight.

regards,

steveL

----------

## mv

 *steveL wrote:*   

> I think it's reasonable enough to encourage people to slim down their busybox

 

I would never recommend this, because bb is needed for repairing, sometimes, and then should better have everything built-in. For instance, there was (and when I tried just a few weeks ago there still is) a bug that if you upgrade gcc in a slot (and have only this one slot installed) then the upgrade and actually even your whole system breaks because the old library link is removed and gcc-config is not able to do what it should because its external tools need this library. To make gcc-config work you first have to reestablish (temporarily) a symbolic link for the previous gcc library - since "ln" is not working at this time you better have a busybox with at least "ln" handy   :Wink: 

----------

## steveL

 *mv wrote:*   

> you better have a busybox with at least "ln" handy

 

Hmm good point. I was really talking about things like start-stop-daemon et al that affect initscript usage. After all, I'm clearly dead-set on keeping awk ;) Clearly in such a situation the statically linked busybox is useful, though. The same reasoning would apply to utilities like umount, so I guess we just wait for the busybox code to support Linux options, and those of us wanting to use busybox as sh in the meantime, can either patch the scripts or remove the applets.

I actually prefer an alias for ssd, since we want to run the installed rc -a, irrespective of shell, so I'm going to keep that in no matter how busybox evolves.

----------

## Dr.Willy

Not OpenRC related, but I noticed that sys-apps/uam doesn't seem to work with bb-sh. Can anyone confirm this?

----------

## khayyam

 *Dr.Willy wrote:*   

> Not OpenRC related, but I noticed that sys-apps/uam doesn't seem to work with bb-sh. Can anyone confirm this?

 

Dr.Willy ... I imagine its due to things like the following (in uam-common.sh)

```
arrtest=$(declare -p ${arrname} 2>/dev/null)

  case "${arrtest}" in

    'declare -a'*)

      isarray=1

      ;;

      *)

      isarray=0

  esac
```

declare is isn't supported by busybox/ash, and is not specified by posix-1-2008

```
# busybox sh

~ $ declare -p test

sh: declare: not found
```

best ... khay

----------

