POSIX-compatible rc.init scripts for Slack (13.0+)
 

This thread will be a replacement/continuation of the stuff discussed over in this post here: What you'd like to see in future Slackware so I/we don't derail that thread.

Feedback should go in this thread.

This here thread basically deals with using Dash shell as /bin/sh on Slackware, and to make that work, repairing some Slackware init scripts to be POSIX compatible.

I'm attaching an updated archive here of all my rc.init scripts from my Slack64-13.0 machine, which I have edited and/or checked for POSIX compliance.
Currently I am using Dash as my system shell (/bin/sh), and am happy with this.
Most of the attached scripts are stock, or very close to it, with the exception of rc.local and maybe rc.local.shutdown, and the intention is for no change in actual functionality of the scripts-- they all work the exact same, only they can work in (theoretically) *any* shell now, not just Bash.
There's a README file in this archive, which might have something useful in it.

The archive is a tar.gz archive, with a .txt extension so it will upload here. Just rename it without the .txt and it will de-compress.

Oct 19 2010 - archive removed for now as it is pretty out-of-date. I may attach a new one in a matter of days or weeks...

Neat! I've applied these to my own system, but haven't gotten around to rebooting yet :p.

Perhaps index the rc.inet1.conf pseudo-arrays by interface name rather than integer

Cool! Do let me know how it works for you; I have updated a whack more scripts from around my system in various locations, so I'll be uploading a new archive sooner than later.

One thing I will be doing though, is making a script to run from cron which will occasionally monitor any files I have modified, in case a package update or whatever, happens to replace something I've repaired. That way I'll know to investigate.
Until scripts get repaired upstream officially, that may be an ongoing process ;)

Sasha

Thanks Sasha!

According to "Ash (Almquist Shell) Variants" ...

http://www.in-ulm.de/~mascheck/various/ash/

...Slackware's ash is *based* on dash.

They just took out the Debian-specific stuff (and the letter "d"). ;-)


Further, our ash thinks it already *is* the install shell:

I agree, ash *should* be our system startup shell, if not our default shell.

As you point out, though, it's part of the AP package set, not the A package set (as bash and tcsh are!).

Thanks gobs for the tip -- and the revised scripts!
You've streamlined my system!

Hi leooooo* :)

I'm glad you've found this useful. I was aware that ash and dash are basically the same thing; but I hadn't looked into what the exact differences are. It just happened that I have read more about Dash than Ash since I began looking into all this, so my focus has been on Dash.
Since Ash is already installed, that might be one less step for folks who are interested in this stuff -- just use Ash, rather than Dash. The point is, with the scripts fixed, people can use their preferred shell, whatever it may be :)
Yes, I seem to recall reading that the Slackware installer uses an Ash shell; someone on that other thread may have pointed that out.

As a startup/system shell it's really good; but as a login shell for general usage, I must say that Bash is much friendlier: The other little shells do not have History, Tab Completion, and a few other goodies that we are all used to.
Actually I believe it was someone else who pointed that out, not me ;)
You're welcome -- I'm glad you find this helpful and/or interesting! Just remember, not much comes with a warranty, including this :D

Best regards,
Sasha

Yah,

I guess I wasn't thinking "friendly" (Linux myopia I guess ;-)

ksh has more useful features and is still more POSIX compliant (they say the POSIX standard was based on the earlier version of this), and some folks swear by it.


Of course, when Ubuntu changed their default shell from bash to dash, they had "#!/bin/sh" scrips crashing all over the place.

I guess I'll still be using bash, but I'll consider writing for ash (for general consumption, anyway). That's it, bash as a login shell, and ash to run scripts. Still should be faster...

"Slackware's ash is *based* on dash" -that's not correct. Slackware's ash is based on an ancient BSD version of ash and uses a whole slew of patches(21). The original sources won't even come close to compiling and the patches make the sources look completely different -and make it compilable.

dash is based on ash -not the other way around. I would not expect Slackware's ash to perform exactly like dash -it may be more lenient about some non-POSIX stuff, while being less capable with other posix-correct code. In other words, trying to use dash to replace ash in the installer would probably also require changes to those scripts.

I'm going to be using Sasha's scripts on my system, but I don't want to use dash as /bin/sh, so I'll edit the scripts to use '#!/bin/dash' as the shebang. That way /bin/sh can remain as a link to /bin/bash.

My sources say Debian took the Linux port of ash and customized it for their purposes (and added the "d") and then Slackware took dash and removed the customizations (and the "d") for their own ash (for Slackware 8).
...whatever


Today I thought of an alternate to by bash/ash plan (above)...

...Z shell!

It's got the best bells and whistles of bash, tcsh, ksh, etc. and more of its own, but it will also emulate a fully-POSIX-compatible sh if called with #!/bin/sh. It goes *both* ways!

Oh, well...didn't mean to get into a fight over shells, to each her own...as for "friendly," I doubt most average folks would consider *any* shell 'friendly' ;-).

Using zsh as /bin/sh kind of misses the point.. It's got exactly the same issues as using bash as /bin/sh. ash and dash are more-or-less strictly POSIX, bash and zsh.. not so much. ash and dash are also light and speedy compared to bash and zsh.

Anyhow, I had to fix a few errors here and there.. and had to correct stuff in /etc/X11/xdm so that it'd properly source /etc/profile in there.

I'm planning on putting this stuff up on GitHub. That fine with you, Sasha?

Of course, that's fine with me; and if the fix-ups you have had to do, would apply to systems in general, and not just yours, then email me the files you fixed, and I'll diff them against my own, and put the fixed versions into the next archive I upload.

At first I was toying with using Dash as a login shell too, which is very likely why stuff related to sourcing /etc/profile may be a bit weird. I've since gone back to Bash as the login shell, so my profile related stuff may already be back as you have put it.

Sasha

http://github.com/tuxdev/slackware-scripts

I've pushed the first set of scripts I've personally gone through and corrected to my own style (using test over [, && and || over -a and -o, indentation, etc).

Yeah, I've been thinking about that...

I'm under the impression that, when operating under sh compatibility mode, zsh does its best to follow POSIX, though I haven't been to confirm how closely.

My idea was to use zsh to check for the POSIX compliance of my #!/bin/sh scripts and still have access to all the bells and whistles in my day-to-day work, but of course I would have to actually call on ash to enjoy the performance benefits.


I look forward to seeing the improvements to Sasha's init scripts.

Oh, nevermind...

According to the bash manual:

No need to go to something as big as zsh (except of the fun of it) just to emulate POSIX compliance.

ash is used for the Slackware installer. It would be nice if it would run during bootup (for speed) and then change the shell to bash for the customary niceties (*hint* *hint*).

Your login shell is whatever is recorded in /etc/passwd.. It's completely unrelated to whatever shell is used in the boot scripts.

I appreciate what you have done, great job.

However, I think initng will be much better idea for moving into the future. I've prepared packages for Slackware (I think I mentioned it somewhere in the forum, PM me if interested), and my machine boots for 30 seconds to desktop with them. Awesome stuff.
I don't think Pat will like it thought. He doesn't look very open-minded.
Your scripts are much more likely to get into Slackware :)

I would like to try those. Can you share the packages?

GrapefruiTgirl: did you send the scripts to Pat by any chance?

sahko, funny you should ask at this moment. :)

For the last few days I have been griping to myself about how I'm going to have to go through all the latest Slack init-scripts again soon, see what's new and patch up my custom ones.

No, I never did send them, or the idea of them, to Pat. I never felt that there was enough of an impact caused by them for them to be something that Pat would consider. -- though the POSIX-compliance-ness of them should be of interest to him perhaps?

I wonder.. tuxdev also came up with a package of scripts too - I wonder if he forwarded the idea to Pat?

Anyhow, if there's interest from the community, and after I go over the scripts again and fix up the latest sysvinit-scripts package in my --current64, perhaps I will send the thing along to Pat and see if there's any interest. I should however set them up for #!/bin/ash rather than #!/bin/dash for obvious reasons (never say "for obvious reasons", right? ;) )

Sasha, I combined your scripts with some of tuxdev's and modified some others. By using them with dash, I was able to get a boot-time of about 7 seconds on a 2.0GHz Pentium 4 machine -normal boot time was around 25-30 seconds on the same machine.
I tried to create a complete set of scripts which get called directly from the existing init routines and not worry about the init 'fragments' which are included with individual packages -letting them use the normal 'bash as sh' code.
I used a 'dedicated' shebang (#!/bin/dash) instead of substituting dash for bash as the main /bin/sh shell. It turns out that using a shebang which points to a link also slows things down. In other words, just using #!/bin/bash instead of #!/bin/sh with the standard scripts would speed things up some...

gnashley,

thanks for the feedback and interesting statistics about speed. You've achieved a significant boot-time increase for sure. Mine doesn't boot nearly that fast at the moment, more like about a minute or so till login at init 3.

I'm currently revisiting this whole scenario beginning with the latest sysvinit-scripts-32 package that came into -current the other day.

I also tried for the heck of it, since I mentioned it earlier, using /bin/ash as the boot shell. Don't try it. It doesn't work-- I thought Dash was strict but Ash is worse -- or maybe it's just plain incapable of doing anything the least bit complicated. My machine wouldn't boot with a #!/bin/ash in rc.M, had to reboot into /bin/bash to fix it.

Finally: I'm curious if anyone has had any issues with lines which source other scripts with arguments, and how you worked around them. Like for example:
In Ash for sure, the argument doesn't get passed to the sourced script. The workaround I used for Ash is:
gnashley: I'd be interested to have a look through the script collection you're currently using on the machine you describe above in post #19-- have you got them all in a tarball that you can email me, or would you provide or send a link where I could download them?

Thanks!

How much processing time would you loose to have symlinks take control of the "start" and "stop"... however that would be messy and ugly.

BTW... if you are already editing the scripts.. you can do:

CMD=start
. /etc/rc.d/rc.syslog
unset $CMD

Then instead of using $1, you could just use $CMD.. or use them both that will assign $1 to $CMD but only if $1 is set.

Perhaps I've missed something here...

Changing every script in /etc/rc.d/ which was executable from #!/bin/sh to #!/bin/bash
did not speed up my boot time by a nanosecond. It takes ~ 34 seconds to boot from the
LiLO splash screen to Linux login in runlevel 3.

I do remember years ago changing several things, backgrounding scripts, to get Slackware
to boot faster. In fact, there was a thread about fastest boot times. But heck, I don't reboot
that often. Once a month usually to use Windoze for Adobe InDesign is about it.

Bruce, are you using bash or dash? The speed increases require you to use dash.

But gnashley wrote: "In other words, just using #!/bin/bash instead of #!/bin/sh with the standard scripts would speed things up some..."

Actually, it seems that POSIX doesn't allow you to source a script with an argument.

Well, that's what a little script called checkbashism.pl told me:
http://sourceforge.net/projects/checkbaskisms/

I used it to switch my init scripts to ash, too, a long time ago. Very useful.
This link is interesting, too: https://wiki.ubuntu.com/DashAsBinSh

So, calling /bin/ash instead of sourcing seems to be OK (sometimes, the scripts don't even need to be sourced).

Here are my initscripts :
http://www.slackware-fr.org/users/ts...cripts.tar.bz2

However, USE WITH CAUTION:
- They're not updated for what I don't use: i.e luks, cryptsetup, maybe some services...
- bash is still used at some places (especially rc.inet1)
- I have disabled some stuff like atd/crond
- I use the '-F' flag for mount, which is unsafe if you have separated partitions like /usr and /usr/local, /var and /var/www.

I could have made a cleaner version without my personal changes (which may be dangerous for others), but unfortunately, I don't have much time...

So it may help people who want to have ash-compatible scripts but it might be "dangerous" to use them "as it".

It's also quite painful to use when running -current since a lot of rc scripts lack a .new/config() thingy in doinst.sh and thus whenever Pat upgrades them your changes are lost. So, make backups.

An other improvement could be to use awk instead of cut|rev|cut|sed.

The funny thing is that, by using a small shell like ash or dash, you have a really good booting time while keeping the simple BSD-like init scripts (compared to the over-complicated upstart, initng and all that stuff). But I don't think Pat is going to accept these small changes.

Hoping it might help you the same way your scripts helped me.

@Bruce Hill -I mentioned that links are slower than directly calling the desired program as a matter of theory -you need to run lots more iterations than in the init scripts in order to observe any difference.

@lumak I tried and discarded a scheme similar to waht you mention.

@Tsomi -you are right that POSIX doesn't support sourcing with appended parameters. My attempts have dealt with this in several ways. Thank you for posting a link to your files -always nice to have more comparisons(until you go crazy looking at diffs, that is...) Thanks also for mentioning checkbashisms (BTW, check the spelling in your link). I used that script (maybe slightly enhanced??) to check everything as a starting point. However, it does not take into account differences between ash and dash.

@Sasha -I am working on complying with your request for archives of my files. Hope to have it all ready by tomorrow. It's been about a year since you, Tim and I were fooling around with this and my work, back then, was still WIP. So, I had to dig back in, archive as new version what were my last efforts, and try to re-acquaint myself with what we were each doing. I spent a couple of hours today starting to write a README which tries to summarize the approach and content that you, Tim and I had going. And it tries to at least mention all possibly problematic areas of the code and the concepts I was using. Unfortunately, we have all (Tsomi too...) have included extraneous changes which are specific to our style tastes or system/hardware needs. if you only want to update your own scripts, just make a diff between script versions in Slackware-current and Slackware-12.1 (maybe it was 12.0 or 12.2) either way, the changes in the stndard scripts are very few compared to the changes in any one of our modified versions, so it'll be easier to use a diff between official versions as a guide than vice-versa.

I was building my scripts and packages for my own distro and could have done things any way I pleased. But still I tried to come up with a package-based solution which would make it possible to convert/upgrade/downgrade an existing system safely (and revertibly).

In my README, I discount the possibility of any of these ever getting into official Slackware. I doubt that PatV is very interested in POSIX-compliance *for itself*. And rocking the Slackware boat is generally frowned on... Perhaps unfortunately, my efforts to make something which installs/upgrade/downgrades cleanly led to some structural changes which were otherwise un-needed.

I'll do my best to get done with the README by tomorrow so I can upload the materials and link to them in this thread. It should be no surprise that my packages are built using src2pkg scripts, but any useful code there could easily be 'ported' to standard SlackBuild scripts. My doinst.sh scripts do much of the heavy lifting vis-a-vis clean installation.

Finally, as I went back through what I had done, I remembered a couple of details which contributed to my lower boot-times, which I have now left out of the builds. Namely, I had backgrounded all the calls to *update-* in rc.M (gtk-modules, pango and mime stuff, etc) Some of this may have already been implemented in Slackware scripts. The other thing I did, which I am sure is not in Slackware is to have commented out a 3-secnf sleep (waiting for USB modules to intialize) -definietely a no-no for a stock system. Still, the combined effect of those two categories of change amounted to 5-7 seconds, so a system using my changes (without those), would still be shaving close to 50% of the bootup time. Also, my test system had very few services being started so YMMV.

My scripts built on some of the most extensive changes which tuxdev and Sasha had already done. Aside from the extensive structural changes I made, I also spent quite a while on getting some of the most time-consuming sub-scripts working faster using ash or dash.

I would much appreciate it if someone made a package or slackbuild out of this, because I've tried this before, but I didn't install dash in the right place, and the computer wouldn't boot properly. After fixing, I wasn't in the mood to try it again.

There's a SlackBuild for dash.
http://slackbuilds.org/repository/13.1/system/dash/

I guess I could try that.

@ gilbert,

you wrote so much in post #26 :) thank you for the detailed reply.

Of course take whatever time you need/want to put together any archive of files you wish to share. I mainly want to look through what you're using, to see if there are any nifty tricks I can throw into my own scripts, and get an idea if there's perhaps any bootup-processes that I definitely should NOT background -- I haven't gone background crazy in my implementation..

You're right -- with the variety of approaches we all have likely taken in this, and the possibly negligible gains vs effort ratio for the general population, it isn't likely that Pat would be interested in this stuff, for better or worse, and also not likely we all could (or would want to) keep a single consistent set of working scripts. And that's OK. :) It's always been more a "Slacker project" idea that anyone can take upon themselves of they're interested in playing around, and each user can decide how far they want to push it. Also, it doesn't really make sense to have just the init scripts be all nice & modern & POSIXy and all that, when there still many other non-conformant and/or just "age-old-tradition" scripts all around in other locations. I don't dare (grep) the whole system and see just how many scripts there are that need a tune-up. :/

Anyhow, thanks for the feedback & thanks everyone for their input & thoughts on this. Gilbert, I'll enjoy looking through your stuff when you get it ready - no rush (P.S. new distro? wh--where!? What?! :D)

Okay, I put in some more time on the README to get this ready today(night here). I've uploaded everything here:
http://distro.ibiblio.org/pub/linux/...sysvinit-dash/

@Sasha - Of *course* you'll find 'nifty tricks' in my code -or maybe not... My work is not intended to replace /bin/sh with /bin/dash. Way too much misery in that for me. My 'distro' -I've mentioned that to you before, but I've (once again) abandoned the idea. It's simply more work than I want to take on -I'm seem to be a cold-weather-only coder, so it would be unfair to any potentil users to lead them astray... I did manage to get a rather-complete set of src2pkg scripts made for most of the basic
packages needed for a system -including X and many optional packages. after some cleanup I'll be uploading them to my site(this fall) for any use they may be to others. There's some pretty interesting stuff there, including my glibc build scripts which create a couple of hundred individual locale packages and my scripts for building X using src2pkg for the most tedious parts...
src2pkg taught me that by working on individual programs I could have more 'impact' than by trying to maintain a whole distro.

@ H_TexMex_H - You can find a src2pkg build of dash here:
http://distro.ibiblio.org/pub/linux/....0/dash-5.5.1/
If you (oh so bravely) decide to build my version of the scripts (using src2pkg) and (really, really bravely) install the package, the scripts should work even if you don't have dash or ash installed -but of course with little result. I put a lot of effort into the doinst.sh so that installing the package would work whether (or not) ash or dash are installed. If you want to use dash, you should have it installed first before installing my scripts. The dash executable should be at /bin/dash, not at /usr/bin/dash (/usr may not be mounted until well into the boot scripts)

I've written a really looonnnngg README here:
http://distro.ibiblio.org/pub/linux/...it-dash/README
which gives valuable insight into my approach to this idea. It is a must-read if you plan to use any of my material. It may also give much-less-valuable insight into any number of other things -if you read between the lines! :=) Happy re-booting...

@ gnashley,

your README is very nice - and I already learned a little thing or two from it. I plan to go through it again piece by piece to specifically address or comment on some points you made in there, but ultimately you pretty much covered the situation in good detail so that anyone wondering "what it's all about" now has a very good idea if they read your README.

Thanks again for your interest & work on this, and also for hosting all these files at your location. :)

Hmmm, Jeremy said that no posts had been lost, but my reply here from yesterday eveneing and someone else's reply to that are not here.
So, I'll repeat -but more briefly.
I've uploaded my sources and src2pkg build scripts here:
http://distro.ibiblio.org/pub/linux/...sysvinit-dash/

There's a pretty long README here:
http://distro.ibiblio.org/pub/linux/...it-dash/README

Oh weird, now my posts from yesterday show up here. Opera weirdness(rare).

Alright thanks, well maybe this weekend, when I'm feeling lucky and brave, I may try them.

@H_TeXMeX_H - on second thought, I think you'd best *not* try building and installing my scripts on Slackware. My packages follow a different naming convention and the way the files are distributed between the packages (sysvinit and sysvinit-scripts) may not fit with what Slackware is presently doing -you might have to manually overwrite and/or remove files in order to restore your system. A better bet would be to wait and see what Sasha does -hopefully she'll come up with a clean way to be able to install/upgrade/downgrade the scripts without braking anything. At the moment I don't have time to test/rewrite to make sure they would work on Slackware.

@Sasha -It's well worth looking closely at tuvdev's scripts for style/compliance pointers. He's formally studied shell programming and follows pretty strict practices which make very good examples which are not likely to lead you astray.

UPDATE..

Well, I've re-gone-through all my scripts in /etc/rc.d but I know I have a few more around the system that I'll have to take a fresh look at. Had a period of time yesterday where I couldn't boot past "Starting HALd" (because it wouldn't start because UDEV hadn't been started and so /dev was sparse) but have that sorted now.

You know what's horrible? /sbin/rescan-scsi-bus. It's a printf/echo and variable-typing pain, although gnashley's version works nicely (some tests make me wonder *how* it's working without complaint). I managed to bork that version for a while too (while editing some of it to my own style & taste) but seem to have it working well now. I'm still tempted to toss out a lot of the verbose output away.

I've had a look at some of tuxdev's scripts; the biggest change I've seen so far is in rc.4, and I have yet to take another look at it, but I thought there was some extra code there too (hard to imagine, it's been compacted so nicely).

Tra la la, on with the show!

I did something very similar with my rc.4 a while back:
Similar approach to Tuxdev's so clearly we were thinking along similar lines, but it doesn't use a variable and that push_back() function for the list of display manager binaries, which makes it a little bit simpler.

I like your approach the most GazL. Very simple, and super easy to add/remove DM's from; would be ideal as the default rc.4 in Slackware. :cool: