I believe Pat has modified the behavior of some of these startup scripts in -current (see early August changelog entries). So, another option is to check out what he did and see if you can manually backport similar changes to your 12.1 install.

Hello, Slackware has this boot up problem because it doesn't take advantage of multitasking. I have solved this issue regarding this command (and others) by appending an & at the end of these slow update commands. Just edit rc.M and change it:

/usr/bin/gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules 2> /dev/null &

Be careful, if, for instance, you append and & at the end of the commands in rc.inet1, subsequently networks services could fail.

Keep in mind that disc head seeks and processor task swaps don't come for free. If you try and run too many things at once (especially on a uni-processor), you can actually make them take longer than if they'd been run in sequence because of the overheads.

Personally, I've never found the boot up time of slackware to be an issue worth worrying about. One of the biggest speed-ups I've noticed was when I switched to jfs filesystems, as it doesn't require deep fscks to check the filesystems out during the boot.

Agreed. I'm not worried about how fast Slackware boots up. Yes. I've also noticed a significant performance boost after switching to the JFS.
Works for me.

That is just theory. Actually, the sh routines are not optimized. What happens when a command like dhcpd is blocked waiting for a time out? In addition several startup routines in /etc/rc.d poses wait calls.

Another slowdown that nobody has mentioned is the "huge" kernel. With 12.1 and the SMP kernel (not sure about the non-smp as I haven't ran it), it dumps a lot of useless info (for my computer at least), such as RAID. IIRC it was the same with 12.0. I ended up rebuilding my kernel (same version), but removed a lot of the features that I wouldn't use on a laptop. Now granted this won't cut your boot time in half, but any gain is a worthwhile gain.

Don't be so quick to dismiss it. Performance tuning is an involved process and very dependent on the specifics. I/O contention is a reality, not a theory. Head seek (thrashing) is just part of it which I cited as an example.

Now, in the particular case of the slackware's startup scripts, you may be able to gain the odd second or two here and there, but you do this at the risk of breaking something.

Take your dhcpd example. As it blocks waiting for an external response, it seems an ideal choice to run in the background: it won't contend for resources with anything else while it waits. However, you may have some later steps of the startup that require all the network interfaces to have their addresses assigned before they run. By putting the dhcp startup in the background it's possible that they may start before the system is ready for them. It looked like an ideal candidate initially, but it turns out to be not so good an idea on reflection. You don't want your database starting before you've synchronised your system time with ntpd, you can't start ntpd before your network interfaces have been setup by dhcp, and so on. When you start adding parallelisms you have to think very carefully about the consequences.

My personal view is that I'd happily trade the 20 seconds or so off the startup time, for knowing that everything will run in exactly the right order every time. 'Keep it simple' it's the slackware way.

I often noticed users complain about boot duration but then they happily waste their time on internet forums!

(yeah, I am kidding of course)

Yeah, chill out. Give up this obsession with speed. Remember the "Slack" in "Slackware".

Try turning off some of the startup scripts, other options I might have listed here:
http://www.linuxquestions.org/questi...ml#post2921723

Really, there are 3 things to do:
1) Look in /etc/rc.d and make unexecutable any scripts that you don't need, for example if you don't have a PCMCIA card, then make unexecutable rc.pcmcia the command would be 'chmod a-x /etc/rc.d/rc.pcmcia'. If you know what you are doing you can also change things in rc.M and rc.S to speed things up slightly more, but it can cause problems if you don't know what you're doing.

2) Build your own kernel, this is a good resource:
http://www.kroah.com/lkn/

3) Use grub or lilo 'compact' option, this can sometimes halve the boot time.

As long as the thing boots faster than the time it takes me to make a cup of coffee, then as far as I'm concerned it's within acceptable tolerances.

I haven't seen it mentioned unless I have missed it, but Slack was always very fast to boot for me until I started using it my laptop. At first, while I was using Ndiswrapper, I had assumed it loading that when I got:

It hangs there for about 30-40 seconds before continuing on with booting. This really slows down the boot time. I am now using the 2.6.27.rc9 kernel (as I do no longer need Ndiswrapper), and still get this message. So, obviously it was not Ndiswrapper causing it. I have read this:

http://www.linuxquestions.org/questi...ng+udev+events

So I am not the only one experiencing this. Slack is the only distro that issues this message. Never have figured it out.

I had problems with a fast running Slackware 12.2 system. After I changed the hostname from 'hydrogen' into 'nitrogen' the system got sluggish. It turned out to be that nitrogen was not listed in /etc/hosts so the boot process could not determine the IP address and hence slowed down on
After adding to /etc/hosts, the problem was solved.

It's easier to have the sys admin / package maker do the right thing than to remedy their mistakes on every startup.

Sure. Do you boot your machine every 5 minutes or so?

When your uptime is in weeks, who gives a rat's ass how long the boot takes?