One of the nicest features of OpenRC/Baselayout 2 (that sooner or later will hit stable I’m sure) is that you can replace bash (which is slow, as its own documentation admits) with a faster, slimmer pure POSIX shell. Okay, so maybe Fedora is now moving away from shells altogether and I guess I can see why from some point of views; but as Nirbheek said it’s unlikely to be suitable for all use cases; in particular, our init system tends to work perfectly fine as is for servers and embedded systems, so … I don’t see the reason we should be switching there. Adding support for dash or any other POSIX sh-compatible fast shell is going to be a win-win situation there — do note that you still need bash to run ebuilds, though!
Now, you can use dash already for the basic init scripts provided by OpenRC and Baselayout, but all the packages need to install proper Posix SH-compatible init scripts if you want to use it with them. Thankfully a number of users seem to care about that, such as Davide last year and Kai right now.
But POSIX compatibility is not the only thing we should actually look out for in our init scripts:
- Eray pointed out that some scripts don’t re-create their
/var/runsubdirectories which is indeed a problem that should go fixed at some point; I had similar bad issues with running my own router based on Gentoo; - one too often misused parameter of
start-stop-daemonis--quietwhich can be… way too quiet; if it’s passed, you’re not going to receive any output at all if the daemon you’ve tried to start fails; and that is a problem; - there are problems with the way the
system-servicesPAM chain is passed through so that limits are not respected (and if that’s the case, caps wouldn’t be respected coming from PAM either); - the way LXC works, init scripts looking just at the process’s name could cause a guest’s daemon to stop if the host’s is closed… this is mostly exercised by
killallbut alsostart-stop-daemonwhen not given a pidfile (and rather just an executable) will have the same problem; and the same goes forpkill, goes without saying.
These are a number of polishing tasks that are by all count minors and not excessively important but… if you’ve free time and care about Gentoo on LXC, embedded or with fast startup, you might want to look into those. Just saying!
Does anyone have benchmarks on how much faster is dash posix shell versus bash ? Specifically at boot time (if I would bet it’s less than 0.4 sec).Also one other thing the init scripts should test is:if the server create a socket than it should wait for the socket to be created before to return success. There is a function ewait<something> for that.This is needed for dependant service to be able to run.example:mysql -> clamd -> amavisd -> postfix
@Francesco: A general benchmark is not possible. It depends too much on the individual system. As a rule, the slower the processor and the less the RAM the more is the difference. On some of my systems the difference is probably 10 seconds or more (pure estimate, not measured), on other systems there is hardly a difference.
> do note that you still need bash to run ebuilds, though!Too bad about that… are there any plans to change ebuilds to use a POSIX compatible shell? It would be nice if we would be able to use a gentoo system without bash installed 😉
As much as I’d like to run “eselect sh set dash” on all my systems, it breaks eselect-postgresql because that stupidly assumes /bin/sh is always bash. (no prizes for guessing who touched it last…)
How can I try dash instead of bash only for init scripts?
Ah, user already use shell from /etc/passwd so I could just change /bin/sh to dash. Works for now, although no mysql at this machine…
In fact the _current_ init functions.sh has around 150 bashisms when I checked a couple of days ago. Perhaps baselayout-2 is better, but I wouldn’t bet on it.Most of the quicker startup comes from the smaller size of Dash, which is also useful in embedded systems, but I wouldn’t myself wish to use Dash as a standard desktop shell.Will
@edd: > are there any plans to change ebuilds to use a POSIX compatible shell?Despite some warning comments, several developers have fight hard to ensure that this will never happen anymore: EAPI=4 will rely essentially on bash-arrays. Some developer has left gentoo due to that bash fanatism, and I can understand him.@cwr: > Perhaps baselayout-2 is betterYes, it is much better, since it was one of the aims of its main developer (it is the one who left gentoo) to make it POSIX. openrc does not use any bashisms, only very few init-scripts of packages still do: AFAIK the main broken scripts are mysql-init-scripts and cryptsetup, although for the latter there is a patch in bugzilla for much more than a year.
What would be the benefit for making ebuilds POSIX compatible? It would (probably) cause more trouble than it’s worth.
One size never fits all; POSIX sh and dash are well suited for the init system because they are _fast_, even if not excessively expressive. Given you want startup to waste as little time as possible, a faster shell is the way to go.Ebuilds on the other hand have _no_ performance requirement whatsoever; even the slowest bash construct is going to be fraction of a percentage over the runtime of a build process. And there, a more expressive language works quite well.So yeah, more than “bash fanatism” it’s a matter of noting where something applies. Roy was right in stating that the init system with bash was going to be slow; on the other hand, he failed to grasp that it doesn’t make a difference in ebuilds.. and it’s going to be way too much trouble to port them anyway.
@mv: > I can see why people want to keep bash arrays; I got interested in init scripts because I wanted to rewrite a pretty scruffy script that annoyed me, and the only way to do it cleanly was with arrays.However, I think the advantages of Dash on boot-up probably trumps the advantages of arrays, especially since Debian and Ubuntu are both moving to Dash.Will
IMHO it would be a more productive use of time to migrate to systemd instead of finishing baselayout-2.
I was wondering how much time it’d take for somebody to comment without reading the bloody post.
> Ebuilds on the other hand have no performance requirement […] and it’s going to be way too much trouble to port them anyway.The point of using POSIX instead of bash is not concerning speed but re-usability of code in different environments. I agree (and probably also Roy did) that ebuilds would not be converted in a foreseeable future in any case. However, forcing the use of bash-array-syntax in the ebuild when there were compatible (and not less readable) solutions suggested is a very strange approach. In fact, in the discussion, the main argument was that the use of bashisms should be encouraged, since most people should know bash anyway. Such an argument, I can really only call “bash-fanatism”.
You’re missing the point entirely. Bash features tend to be more expressive and safer.What you call “bash fanatism” is pure pragmatism in light of “most people wouldn’t know how to do stuff in pure POSIX sh”. And there is *nothing* that hinders or helps re-usability in the choice of sh or bash; in either case the code is *just used by Gentoo ebuilds*.Rather, your short-sightedness on the usefulness of keeping the use of bash available on ebuilds is what burned down Roy, and what is going to achieve, if anything, more hatred for OpenRC.
Well, in fact bash array syntax is _considerably_ more readable than Dash array equivalents – I’ve just spent a couple of evenings trying various approaches in Dash for an init script, and none of them looked especially pretty.I can see the advantages of Dash for inits, but I really can’t see the advantages for parsing ebuilds.Will
> most people wouldn’t know how to do stuff in pure POSIX shNow you are missing the point. Maybe some people don’t know how to do it. Fine, they can use bashisms. But is this a reason to force everybody to use bashisms in ebuilds by providing certain functionality only in terms of bash-arrays when it could be done by providing functions?> in either case the code is just used by Gentoo ebuildsThis is already a misconception. You should be able to copy a function you need from a shell script into an ebuild and vice versa. This is what I call re-usage of code.@cwr: bash array syntax is considerably more readableWhat is more readable in
COMPRESS_LIST=("My Doc" "another doc" "${DOCFILE}")COMPRESS_LIST+=("yet another doc")than inPush COMPRESS_LIST "My Doc" "your doc" "${DOCFILE}"Push COMPRESS_LIST "yet another doc"which would be essentially the difference in ebuilds? (This is just one of many possibilities; instead of Push(), one could also provide a CompressFiles() function or something similar.) And accessing the array is as simple aseval "set -- ${COMPRESS_LIST}""${COMPRESS_PROG}" -q -- "$@"for i do; ...; donecompared to the bash-only"${COMPRESS_PROG}" -q -- "${COMPRESS_LIST[@]}"for i in "${COMPRESS_LIST[@]}"; do ...; doneSo really (besides writing the Push-function which could be provided in the default-environment) it is not harder, not longer, and not less readable, but the code can be reused.