Skip to main content ↑ ↓
Topic: Some core services use Bash, even though their scripts are POSIX (Read 481 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Some core services use Bash, even though their scripts are POSIX

A few core dinit services forcefully use Bash to run their scripts, even though they don't need to, because the scripts they run are POSIX compliant. I found this out when trying to change my shell completely to Dash, since I wanted my system to be as light and fast as possible.
After uninstalling Bash, changing the shell for all users to Dash and symlinking /bin/sh to /bin/dash, my system was unable to boot properly and sent me into recovery mode. Immediately, I noticed almost all the services either were stopped or had failed to load, with only a few actually throwing an error. The first one to catch my eye was from the dbus-pre service, which said:
Code: [Select]
dinit: dbus-pre: execution failed - executing command: No such file or directory
I suspected that uninstalling Bash may have caused something with that service to break, so I checked the service file in /etc/dinit.d, and sure enough, the stop-command line read:
Code: [Select]
/bin/bash /usr/lib/artix/sv-cg.sh down dbus
I booted into a USB and changed that line to use /bin/sh instead of /bin/bash, and did the same for the dbus script in /usr/lib/dinit/pre. I then tested if dinit would boot successfully by running dinit -o, but all the services were still failing. This had me stumped for a while, until I realized my screen may be too small to fit all the services in at once. I ran dinit -o | more to see them all, and then I found the culprit:
Code: [Select]
dinit: cgroups: execution failed - executing command: No such file or directory
It was the same thing as the dbus-pre service, except now it was the cgroups script in /usr/lib/dinit.d. I changed /bin/bash to /bin/sh in the command, reran dinit -o, and it finally booted normally! The USB boot started having a panic attack with multiple dinit sessions running at once, but I was able to dig my way out of it, unmount the root partition, and reboot into a working system once again. :D
As fun as it was figuring everything out though, I'd much rather have these services pre-configured to use /bin/sh instead of /bin/bash, so anyone who wanted to replace Bash with a different shell wouldn't have to worry about breaking their system. Every service script I've seen other than the ones I've mentioned either are already ran with /bin/sh or have a shebang that runs it, so it shouldn't be that difficult to change. It would save the crazy people like me a lot of headaches in the future. ::)

Re: Some core services use Bash, even though their scripts are POSIX

Reply #1 –
Not to argue about POSIX, but wouldn't it be simpler to just symlink /bin/sh to /bin/bash and only have one thing to worry about?

Re: Some core services use Bash, even though their scripts are POSIX

Reply #2 –
Quote from: Maoijoon – on
After uninstalling Bash
Why do that? Just leave bash in place and every thing should work.

I couldn't know without looking but maybe some of the service scripts with a #!/bin/bash shebang contain bashisms ?

You can check that https://wiki.archlinux.org/title/Dash#Identifying_bashisms

Re: Some core services use Bash, even though their scripts are POSIX

Reply #3 –
One sin worse than using bashisms is shebanging bash even when you don't.

Re: Some core services use Bash, even though their scripts are POSIX

Reply #4 –
Quote from: nous – on
wouldn't it be simpler to just symlink /bin/sh to /bin/bash and only have one thing to worry about?
That would technically work in my case, but running any script afterwards that has a Bash shebang line and/or uses bashisms could produce unintended behavior. For smaller scripts, it's most likely not an issue since it'll just error out. However, scripts that are more complex, source others, or designed to continue running even after a command fails may cause damage to either themselves, any program they're attached to, or at worst, the entire OS.
I'd rather not have any shell symlinked to /bin/bash because of this. The worst I would get by not doing that is a command not found error for scripts that call Bash, which to me is more preferable to having a small chance of breaking my entire system.

Re: Some core services use Bash, even though their scripts are POSIX

Reply #5 –
Quote from: gripped – on
Why do that? Just leave bash in place and every thing should work.
Because I want to, and I always write scripts with POSIX in mind, so I have no need to use it.
Quote from: gripped – on
I couldn't know without looking but maybe some of the service scripts with a #!/bin/bash shebang contain bashisms ?
That's the thing though. I checked using a self-made script and none of the service scripts have a Bash shebang line, nor do they contain any bashisms. The only pre-installed script that did was /usr/bin/gettext.sh, and that was just to check what shell it was running in so it could use the proper echo function. There is no reason for any of the services to be running their scripts in Bash when they're already written for POSIX.

Re: Some core services use Bash, even though their scripts are POSIX

Reply #6 –
Quote from: Maoijoon – on
Because I want to, and I always write scripts with POSIX in mind, so I have no need to use it.
Fair enough. I misread your post and thought you were mainly talking about shebangs.
I don't see the need for the hardcoding of /bin/bash in commands either ?

Re: Some core services use Bash, even though their scripts are POSIX

Reply #7 –
Quote from: gripped – on
I don't see the need for the hardcoding of /bin/bash in commands either ?
For simple commands i agree too, just use /bin/sh...
...and only if there's heavy variable usage where splitting(zsh) or a different set command(fish) can affect it then it can use /bin/bash.

I know the problem that happened few months ago with the cgroup parameter thing in the /sbin/init script using a bash syntax but not having the shebang set to it, but for a simple init executed script you really don't need bash.