It looks,slackware is taking too much time to boot.
It's starting daemons at boot time.

What are those daemons that i can stop at boot time to increase booting time?

What's the best way to stop starting daemons at boot time?

1) Make unexecutable anything in /etc/rc.d that you don't need, stuff like rc.gpm, but not important things (look through them and they should say what they do).

2) If you use lilo, make sure to add 'compact' to lilo.conf and then run lilo if it wasn't already there.

3) Compile your own kernel, this will improve boot speed and app start times a bit.

I wrote a how-to thread at some point on here, but it's kinda outdated, maybe I'll update it.

1 members found this post helpful.

It's grub boot loader.
How does compiling own kernel improve boot speed?

It will reduce the time taken probing for hardware devices that don't exist and that it's never going to encounter.

Yeah, and for older computers it will greatly decrease boot time because it has less to load into RAM.

I can tell you that with my old Vaio laptop each one of these steps pretty much halved the boot time. Grub is slightly faster even than lilo compact but not by much.

Ok, so, after looking at my old post here:
http://www.linuxquestions.org/questi...ml#post2921723

It seems that only the following apply now:

1) Make un-executable anything in '/etc/rc.d' that you don't need. For example:

2) Install grub or use lilo 'compact' option. You choose. Grub is slightly faster from what I can tell, but is not available for 64-bit.

3) Compile a new kernel. Here is a good guide:
http://www.kroah.com/lkn/

a) First, start with the generic kernel, and build from there. Run 'make mrproper', copy in the '.config' from the generic kernel, and then run 'make menuconfig' (or whichever one you prefer).

b) Search for the words 'not', 'found', 'no', and 'error' in 'dmesg', and take appropriate action ... removing what fails anyway.

c) disable 'pcspkr', unless you like annoying beeps every time you make an error. (disable raid/md if you don't use it)

d) make floppy a module rather than built-in (on some machines, this is the only way it will work)

e) Under 'Block layer -> IO Schedulers' read the help on all of them and see which one you think is best. IMO, the best are CFQ for desktop, and deadline for database/server.

f) Under 'Processor type and features':
i. Make sure to select your processor in 'Processor family',
ii. Enable/disable SMP (Symmetric multi-processing) if you have or don't have it
iii. Disable 'Generic x86 support' unless you're making your own distro
iv. Put max # CPUs (for multi-core)
v. Enable/disable hyperthreading for P4
vi. Enable/disable multi-core and/or SMT scheduler suppport
vii. Disable local apic
iix. Read and choose 'Preemption Model' (Voluntary is good for desktop)
ix. Enable/disable high memory support: if you have near 1GB RAM, enable it
x. Set timer frequency acordingly (1000 Hz for desktop)
xi. Maybe try enabling '64-bit memory and IO resources' if you have 64-bit processor
xii. Turn off 'Compat VDSO support' (glibc-2.3.3 or later)

g) Don't forget to fully enable your filesystem

Also note the new experimental kernel feature that can help in trimming down the kernel:
http://www.linuxquestions.org/questi...localmodconfig
you still have to know what you are doing tho.

2 members found this post helpful.

I've speeded up time-to-login by backgrounding a non-essential item in rc.local and am planning to do more

1 members found this post helpful.

I've been testing the use of 'dash' as the shell for the main init scripts. All else being equal, boot-time dropped from 17-18 seconds to 6-7 seconds. I really wanted to use dash for all or most of the init scripts, but many require major bash features and trying to maintain a full set of them altered to use dash is a chore. But just by fixing the ones included in sysvinit-scripts gave an astounding improvement.

You should also do this: http://humanreadable.nfshost.com/sdeg/boot_time.htm
Its really uneeded to execute these commands every single time your machine boots.

So, could you provide a list of the ones where it's safe to use dash ? Pls.

@ TEX -- If you have dash shell installed, you could simply execute each script using dash:

shell$ dash ./rc.script

and note which ones execute cleanly and which ones return errors. This should be "nearly" 100% reliable.

Kinda klunky, yes, but until someone provides an accurate list, it will work.

Myself, I have modified all my rc.init scripts (the incompatible ones) to work with Dash, as of that other thread I posted a while back about "POSIX init scripts for Slackware" or "Dash shell as /bin/sh for slackware" (something like that), but like Gilbert says, unless the scripts actually get fixed/changed up upstream, it's an ongoing task to diff the scripts that come with a new Slackware, against either your modified ones or against the default previous ones.

tuxdev posted a bunch (of fixed ones) on github too; you can find his link inside my thread mentioned above.

I *can* tell you, rc.inet1, rc.inet1.conf and rc.wireless are NOT compatible with Dash. As for the others, off top of my head I can't recall exactly, but in the next few days (since I just installed *most* of -current) I'll be having another look at the new init scripts, and this time (since you may be interested) I will keep a list of which ones I modified vs which were OK.

Hope this helps for now..
Sasha

PS - I've also learned, contrary to my intention in that above mentioned thread, that at this time, linking /bin/sh to /bin/dash provides a bit of a headache sometimes. Not a big one, but a headache nonetheless, so if you plan to use any modified scripts that work with Dash, the best plan would be to change the shebang to read #!/bin/dash

2 members found this post helpful.

Ok, thanks, I'll try it out.

i just followed all the suggestions in this thread; using dash for init scripts, commenting out services that need not be started at every boot and putting those scripts into cron.daily, and compiled a custom barebones kernel, and boot times are much improved

also nothing seems to be broken!


i hadnt compiled my own kernel in a long time, and never before on this machine, so that last part is a nice surprise...

and note to any out there who might forget this part; append a local version string to your kernel so in case you do miss a vital kernel module, the old modules will still be preserved in /lib/modules/2.6.33

Soooo...

Why not use /bin/ash instead? That even comes with Slackware.

ash is currently broken on 64-bit systems. I did not link /bin/sh to /bin/dash. Instead, I changed the shebangs in the relavant scripts to explicitly use dash. Using ash or dash as /bin/sh will cause lots of problems elsewhere, even if you make the init scripts run cleanly.

I used some of sashas and some of tuxdevs scripts as a starting point and fixed/adjzsted from there. The main scripts I mean are rc.S, rc.M, rc.4, rc.6 and rc.K.
There are really only a few changes needed for just these. The problems start with the other ones called by these and the way they are called. You need to change all the instances of:
. /etc/rc.d/rc.blah start
to:
/etc/rc.d/rc.blah start
or:
sh /etc/rc.d/rc.blah start
as dash will not pass the 'start' to the child process for some reason. I worled on some of the externals and got most of them working but decided that it would not be good to try and maintain all of them.

tuxdev has modified rc.inet1 and rc.inet2 to work with dash. It would be good to use them as those scripts are long and complicated so any speedups there are significant. I also go rescan-scsi-bus.sh working with dash, but it is mostly not used anymore. Since most of the scripts are distributed with their package, it would be more difficult to manage hacked scripts as a packager. What I mean is, that if the user is to have a choice between using dash or bash, then each package with a 'dashified' rc script would have to offer both scripts and a way would have to be devised to install and use the correct one on a users' system.

Still, as I said, there was a quite significant improvement by modifying only the main scripts. I suspect that they would also work with ash, but I think there is no good reason to go on using ash-0.4 since it is no longer maintained, while dash *is*.